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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list