Re: Lowering the barrier (was: Re: build systems)

["Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>]

On 10/11/2007, Emmanuele Bassi <ebassi gmail com> wrote:

On Sat, 2007-11-10 at 15:06 +0100, Mikkel Kamstrup Erlandsen wrote:

>  * GObjects are conceptually difficult when you have standard
> knowledge of C# or Java

you know you don't have to use GObjects with C, right? you can write
native C# and Java applications.

I realize that I could have been more clear here. What I find problematic is that the barrier to contributing native code is to high.

I have been putting a lot of time into deskbar in the past and I can not tell you how many times I've heard "oh, great - yet another Python daemon", or "why did you not wrote it in C?".  Setting up a PyGTK project with Python distutils is extremely easy, and about as low barrier to entry as humanly possible.

>  * Autotools are exceptionally hard to work with

they are not "exceptionally hard". they require documentation, and we
don't provide pointers to it in the right places. autotooling an
application or a library takes ten minuts in a basic setup, and if you
require more complex handling then you'll find that all the replacements
will not handle the environment as well (if at all).

To me, personally, they where exceptionally hard. My teaching experience from uni tells me that if one  person thinks something is hard - so do at least 50% of the class.

Yes, it takes ten minutes to autotool a *basic* setup if you know how to do. But doing things that are expected for packages like, passing make distcheck, building gtk-doc, build a few test/examples, install headers or other files correctly takes a long time if you are not comfortable with autotools.

>  * Some parts of the Gnome API are just plain hard to use. Ever tried
> implementing a panle applet? Wonder why we have to many apps using
> tray icons?

from a cursory glance in my chat logs of #gnome on irc.gimp.org and
gtk-list archives it seems that everybody start with panel applets; I
started with those as well. it's not hard to write a panel applet: it's
hard to *debug* a panel applet - but that's because of the way panel
applets work.

Yes, everybody starts with panel applets - but I can name three projects of the top of my head that ended up resorting to tray icons even though an applet would be the right solution. I shall not point any fingers though.

this doesn't mean that the panel applet API is "easy". or, for that
matter, that the entire platform API is easy; we are still missing bits
and pieces (lockdown? desktop state? document models?) and we are still
paying the price of having cruft lying around.

>  * General API docs are not as good as they could be. Compare QT4
> documentation with GLib to see the point.

maintainers in glib and gtk+ have been incredibly responsive in pushing
documentation patches; people rarely have to wait a day for a commit
authorisation (insert kudos to Matthias and Tim here). we need more
people fixing the documentation and attaching patches to bugzilla. it's
quite easy.

Yes it is quite easy. GLib and Gtk  docs are quite good actually, but they are not exceptionally good. I am not complaining; I am only trying to hash out a strategy for making the learning curve less steep.

>  * It is sometimes hard to grok how an application or lib is
> internally structured. While
> http://library.gnome.org/devel/platform-overview/stable/ goes some of
> the way describing the platform as a whole, the internal structure of
> apps and libs are sometimes elusive.

you have the code. if the application/library is complicated pester the
maintainers for explanations and submit a patch documenting the nasty
bits. or removing them, if possible.

Yes that is obviously a solution to the problem - but exactly the solution I claim have failed (to some extent at least) hitherto.

That is why I suggested the alternative route in my "Points of action" which have now been snipped from the mail history. Autogenerate UML and have the some dev in-the-know write half a page about the structure.

>  * Write a "GObjects for Java/C# Developers" document (or maybe two
> separate docs) meticulously explaining the concepts of classes and
> object instances compared to Java/C# objects for the lay hacker

this is a false problem: since you can avoid writing GObjects in C and
use native data types instead, what you need to do is refresh the
GObject tutorial.

I do not understand what you are trying to say here. That people can just use plain old structs or that they can use bindings like Java, Python, Mono?

Assuming the latter - that is not the point I am trying to address. I want to make it easier to hack on the C libraries. Consider for example Gtk's recent call for extra man power.

Myself coming from a Java background, I can tell you that it was non-obvious to me how GObjects worked with my (very) limited knowledge I had when starting getting interested in this whole Gnome business.

>  * Make Anjuta better at GObject/Ginterface and Autotools handling. It
> is already good, but make it *excellent*

I imaging that Anjuta maintainers are accepting patches for these
points.

> * Lobby for distributions to create a gnome-developer-studio package
> installing all build deps, documentation, latest anjuta, everything
> you need to hack on Gnome. Pimp those packages on the official Gnome
> pages.

GNOME already has a development suite; distributions should already have
picked that up.

I do not know of such a one-stop-shopping solution in any distro. If they do they are certainly very well hidden.


I think there is no denying that Gnome development (in native C) has a high barrier to entry, and from this thread's subject I think that is what we are trying to lower.
Saying to each of the points that I raise "this is FOSS, you can just send patches", amounts to claiming that the way things have been done till now is fine. Then I wonder how we ended in this position in the first place...

What I tried to do in my last mail was:

 1) Pin down a list of problematic points
 2) Create a list of actions to address these points in a pragmatic way

As I read your mail you have just waived every point I tried to raise in 1). That is fair to do, as I may be wrong, but does not really help further the subject of this thread.

Cheers,
Mikkel