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

[Emmanuele Bassi <ebassi gmail com>]

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.

>  * 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).

>  * 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.

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.

>  * 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.

>  * 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.

>  * 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.

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net