GNOME Bugzilla – Bug 693569
Stop using deprecated GTK+-3 API
Last modified: 2013-02-12 08:41:53 UTC
Quite some API has become deprecated since 3.0 days, so port to the replacements when using GTK+-3. The GtkTable => GtkGrid ports is quite invasive with regard to #ifdefs, but as I understand it, easytag will eventually move completely to GTK+-3, so it's a temporary measure. If the intention is to maintain the GTK+-2 code long-term, it'd probably better to use a small compatibility layer instead.
Created attachment 235675 [details] [review] misc: Fix compiler warning
Created attachment 235676 [details] [review] bar: Stop using GtkHandleBox The widget is deprecated in GTK+-3, as it is generally considered bad UI. In this particular case it is even completely pointless, as there is only a single place in the UI where the toolbar can be placed.
Created attachment 235677 [details] [review] misc: Don't use gdk_cursor_unref() with Gdk3 GdkCursor is no longer a boxed type in Gdk3 but a full-blown object.
Created attachment 235678 [details] [review] Use GtkGrid instead of GtkTable when build with GTK+-3 In GTK+-3, GtkTable has been deprecated in favor of the new GtkGrid widget, so use that throughout the code base.
Comment on attachment 235675 [details] [review] misc: Fix compiler warning Pushed with minor changes as commit fdf8cc1151e5590033aad13b6ce28d3b84ef4ba2, thanks.
Comment on attachment 235676 [details] [review] bar: Stop using GtkHandleBox Pushed with minor changes as commit 14473f69b312de6f9ce3aecfd55b0c4308b15f56, thanks.
Comment on attachment 235677 [details] [review] misc: Don't use gdk_cursor_unref() with Gdk3 Pushed with minor changes as commit cde61f8f5ceb5cbaacf0574b157bf5393a395b66, thanks.
Review of attachment 235678 [details] [review]: The other patches were straightforward (and I updated HACKING to take into account the minor changes that I made). This is a bit more difficult though. I am not particularly interested in making the GTK+ 3 support work without deprecations, but if you think that you can accomplish this using a similar approach to how this has been done in EasyTAG so far, then it should be fine. See src/gtk2_compat.c for the current approach, which is to use the GTK+ 3 versions of types in the main sources, and have a compatibility wrapper in src/gtk2_compat.c. If you cannot do it without lots of ifdefs in the main sources, I would rather leave the experimental GTK+3 support with the deprecation warnings.
Created attachment 235748 [details] [review] Use GtkGrid instead of GtkTable when build with GTK+-3 (In reply to comment #8) > if you think that you can accomplish this using a similar approach to > how this has been done in EasyTAG so far, then it should be fine. > See src/gtk2_compat.c for the current approach, which is to use the GTK+ 3 > versions of types in the main sources, and have a compatibility wrapper in > src/gtk2_compat.c. It is definitively possible to come up with a compatibility API, but we cannot always use the plain GTK+-3 versions (unless we want to resize tables continously, we do need to pass a valid size to gtk_table_new(), and GTK+ 3 uses child properties for some of the parameters to gtk_table_attach()). > If you cannot do it without lots of ifdefs in the main > sources, I would rather leave the experimental GTK+3 support with the > deprecation warnings. Updated patch to not add any more ifdefs :-)
Comment on attachment 235748 [details] [review] Use GtkGrid instead of GtkTable when build with GTK+-3 Thanks! I applied this with some minor style changes, and pushed it to master as commit a57d0ee350c2dd2b9b04bdd98a7633a0113f2ccf. As I no longer get any deprecation warnings when building against GTK+ 3, I re-enabled the deprecation defines.