GNOME Bugzilla – Bug 151855
Update for GTK+ 3.0 and GNOME 2.30
Last modified: 2009-08-19 17:49:30 UTC
Drivel 1.4 will be targetted at GNOME 2.8, so we'll need to figure out any API changes, etc., and update Drivel to comply with them. The only one I know of right now is the MIME scheme change.
GNOME 2.8, or 2.10 ? If we target for 2.10, which is 6 months, one week away, we'll get things like the new GTK+, and I'm sure lots of other magic.
Very true... we should probably see how development goes and make the call later, once we have an idea of what GNOME 2.10 will include. GTK+ 2.6 should be out in 3 months, so we could still target that.
With GNOME 2.10 less than three months away (and on schedule, yaay!), I'm thinking we should target that for Drivel 1.4. Tenatively, I'd suggest looking at late-March/early-April for the Drivel 1.4 final release date.
Punted to Drivel 2.2--let's wait until GNOME 2.10 has a wider installed user base.
GNOME 3.0 is around the corner, 2.26 is already available in Debian and 2.24 in Debian stable. I'll check this out once 2.0.4 is ready for release in a few weeks.
2.0.4 has been released so I've started looking at Gtk 3.0 support - one step is to migrate from glade to GtkBuilder. I've got a patch for trunk/ which is the result of migrating the XML to GtkBuilder and the basic changes in the source code to migrate. Problems exist though - GnomeApp and Bonobo don't seem to be supported although this could be because the patch completes the Gtk component but not the Gnome support in Builder. Patch is at: http://drivel.svn.sourceforge.net/viewvc/drivel/patches/glade-gtkbuilder-migration.diff?revision=695&view=markup
libgnome2-0 is also going away, so the issues about GnomeApp (and therefore bonobo) need to go away as part of the overall migration. Hmm, this is turning into quite a large job. See also http://blogs.gnome.org/pbor/2007/09/24/delivering-the-killing-blow-to-libgnome/ So, a new XML file is going to be needed, starting with a standard Gtk window instead of a GnomeApp.
I've got a suitable Glade file - it's done as a patch at the moment but with the other changes, probably easier to do the change in the glade-3 editor. (By cutting the contents of the bonobo widgets, pasting into a new Gtk window, rename the old one, give the new one the original name and remove the old.) Remaining issue is the occurrence of gnome_appbar_* functions and gnome_help* in src/*.c as well as the port of GnomeVFS to GIO.
I've updated the GtkBuilder file and merged the previous patches into a single one. Nevertheless, the bonobo widgets and GnomeApp widgets (and the two Custom widgets) are gone. Remaining issues are libegg and the few function calls that remain. No news on the GVFS->GIO port so far - plan is to get the rest working before starting that port.
For the libgnome(ui) removal part: ./drivel/src/login.c:#include <gnome.h> ./drivel/src/tray.c:#include <gnome.h> ./drivel/src/insert_poll_dialog.c:#include <gnome.h> ./drivel/src/main.c:#include <gnome.h> ./drivel/src/dialogs.c:#include <gnome.h> ./drivel/src/about.c:#include <gnome.h> ./drivel/src/network.c:#include <gnome.h> ./drivel/src/journal.c:#include <gnome.h> ./drivel/src/query_music_players.c:#include <gnome.h> ./drivel/src/login.h:#include <gnome.h>
There is too much going on with this change to handle it all as patches. I've got a local tree that omits all the old stuff and builds against the versions we need for GTK3.0 (including gtksourceview-2.0) but it does this by commenting out sections of code. Need to implement GtkRecentView instead of libegg (removed) Need to swap from GnomeApp to GtkWindow Need to swap from gnome_about* to GtkAboutDialog Fix the problems that result. :-) I'll commit those changes, close the relevant bugs and then work on getting drivel back into a working state. Bumping version to 3.0.0 for the above changes. (2.1.1 isn't worth working on because it's dependencies will be old before it's ready.) Only once 3.0.0 is working reasonably will I start on the GnomeVFS->GIO transition. Closing the actual bug report, the issues that remain are handled separately.