GTK+ 3 migration
Inkscape currently makes use of the GTK+ 2.20 library API. Ultimately, we will need to switch to the new GTK+ 3 API. This version of the library introduces a number of major changes that are incompatible with GTK, so we need to make some changes to Inkscape.
- 1 Building Inkscape against GTK+ 3
- 2 Guidance from upstream
- 3 Deprecated symbols
- 4 Build against external GDL
Building Inkscape against GTK+ 3
First, configure Inkscape to build against GTK+ 3 using
configure --enable-gtk3-experimental. I prefer to use a separate subfolder for these (broken) builds.
# Create a subfolder in the source directory for the experimental builds mkdir build-gtk3 cd build-gtk3 # Configure to use GTK+ 3 ../configure --enable-gtk3-experimental
After this, you can build as usual. However, as there are a huge number of errors, it is useful to instruct the build to continue even if errors are encountered. This is achieved by using the "
-k" flag with Make. It is also helpful to dump a log of the errors (>5000 lines at the time of writing!). In summary, I use something like:
make -k 2> gtk3-experimental.txt
Guidance from upstream
The GTK+ 3 reference manual offers some guidance for the upgrade process.
Inkscape currently makes use of a number of deprecated GTK+ symbols. We need to get rid of all of these as part of the migration. Some are very easy to replace. Some are a little more challenging.
Although Inkscape is configured to use the "-DGTK_DISABLE_DEPRECATED" compiler flag, this does not trap all deprecated symbols (because many Gtkmm headers disable the flag!).
An incomplete "to do" list follows:
Switch to gobject
The GtkType and GtkObject API has been replaced by the gobject library. One of the few remaining issues here is that SPCanvasItem is a subclass of GtkObject. However, this part of the class hierarchy is currently being rewritten, and will be based on a different parent class.
Use accessor functions to GtkWidget
Accessor functions such as
gtk_widget_has_focus() should be used instead of deprecated macros such as
Get rid of "visual" functions for GtkWidgets
The visual for a widget, and also the default visual is now derived from the colormap for the widget and the default colormap.
gtk_widget_pop_visual() now do nothing. Since the visual always had to match that of the colormap, it is safe to simply delete all references to these functions.
- Done Valavanisalex 09:55, 23 June 2011 (UTC)
Don't use GtkNotebookPage
GtkNotebookPage structure has been removed from the public header files; this was never meant to be a public structure, and all functionality that could be done by accessing the struct fields of this structure should be accessible otherwise.
Switch from GtkCombo to GtkComboBoxEntry
- Done. A few symbols are left in #if/#else blocks in src/dialogs/text-edit.cpp to allow build compatibility with GTK+ 2.20. These can be removed once Inkscape has bumped its dependency level to GTK+ >= 2.24. Valavanisalex 09:46, 23 June 2011 (UTC)
Get rid of GtkAction proxy functions
gtk_action_connect_proxy has been deprecated since version 2.16 and should not be used in newly-written code. Use gtk_activatable_set_related_action() instead.
Merge GtkRuler into Inkscape
The GtkRuler class has been completely removed from GTK+ 3, and will not be replaced. GIMP got around the problem by merging the GtkRuler code into their own project.
Build against external GDL
We currently use our own fork of the GDL library (based on GDL 2.30.0). Eventually, we need to get rid of our own fork, and build against the external library. Progress is being tracked at https://bugs.launchpad.net/inkscape/+bug/792115
Most of our local changes to GDL have been accepted upstream in GDL 3.3.4 and higher. The only remaining issues are minor:
- the title bars of docked dialogs do not change colour when they gain focus
- floating docks will show up in the system taskbar
Fixes for both of these issues are being worked on upstream.
When experimental builds are configured, a search is made for a suitable external version of GDL. If GDL >= 3.3.4 is available, then it will be used in place of our internal fork.