GtkApplication class: I’ve updated the application class page on the wiki. Now, it has an updated layout of the API (which is what I’m currently working on) and the design requirements it should fulfil. While writing it I had some sort of epiphany about the whole library consolidation effort and its perception among the platform developers. Project Ridley as it stands is a double-edged sword: on one hand we’d like to have more functionalities moved from external libraries to GLib and GTK+; on the other hand, the size of the platform libraries maintainer teams is not growing at the same rate. If we are to move widgets, features and whatnot to GTK+ we must be sure not only that someone is actively working on them after inclusion, but also that someone is willing to work on the rest of the codebase, in order to review the patches leading to the inclusion of new functionalities. So, waiting for Project Ridley to come to the rescue is not going to cut it anymore: if you are proposing to move some functionality from a library to GLib or GTK+ be prepared to work on the whole code and not only on your pet feature.
GtkUnique: since a “single instance application class” doesn’t really make any sense without an “application class” to make it inherit from, I’m punting the GtkUnique inclusion in GTK+ until the application class lands in first – and that makes it part of the post-2.12 masterplan; hence, I’m going to remove the gtk namespace from gtkunique and releasing it as a standalone library for the time being. I’ll commit the namespace switch before this weekend: it’ll switch from GtkUnique
to Unique
; everything else will stay the same. Remember to check it out from GNOME SVN server:
svn co http://svn.gnome.org/svn/gtkunique/trunk
GConfig: as I mentioned in the last blog post, I’m working on the next iteration of GConf. Aside from ongoing design and API churning, I’ve also submitted a talk proposal for the next GUADEC about how to tackle the whole ‘GConf issue’. GConf is part of the core GNOME platform, and it has been so since 2000; it’s almost seven years old, and now it begins to show its age. Since 2001, Havoc has been asking the community to implement the same set of (five) features; no one has answered his call yet. Maybe the community is to be blamed for this; maybe we need to rethink part of the GConf design to allow someone other than ‘the usual suspects’ to fix GConf shortcomings and add new features. For instance: the backend API is a really nasty piece of code and it’s not easy to drop a new backend into an existing GConf installation; probably, that’s also why, after all these years, we still have only the XML and had to wait a long time for the evo-ldap backends. I’m going to put a page on the wiki with what kind of API I’m thinking about.
talks: aside from the GConf talk, I’ve also proposed a talk/tutorial about the Perl bindings for GTK+. I’ll also do two talks about Perl, GObject and GTK+ at this year’s Nordic Perl Workshop which will be held at the end of April in Copenhagen.
A couple other notes on gconf in this mail, if you aren’t on gconf-list: http://mail.gnome.org/archives/gconf-list/2007-February/msg00014.html
My opinion on the transition path:
– start with a new source tree to do a clean new dbus-based daemon, library, and storage format with much less code and a nicer test suite; try to get tons of peer review on this early on and ongoing so it’s really credible as a new replacement
– have a read-only backend for the new daemon that reads the old gconf xml files
– have a backend for the old gconfd that talks to the new daemon, and change the default in old gconfd to be the new daemon backend, OR just leave old gconfd alone is another possible option
If the new daemon and library are very big or difficult, something is probably wrong… the current libgconf/gconfd are wildly too much code due to various design mistakes documented on the gnome.org gconf project pages.
Rock on Emmanuele these are all great stuffs that will *really* improve the gnome’s users experience!
Thanks a lot!
Dude, you rock my world! :-)
So this GtkApplication class would have things like auto-saving the windows geometry?, that is one thing that EVERY application has to do on its own…