GNOME Bugzilla – Bug 572178
Remove deprecated GTK+ symbols
Last modified: 2010-06-24 16:02:19 UTC
http://live.gnome.org/GnomeGoals/RemoveDeprecatedSymbols/GTK%2B ./engines/glide/src/glide_gtk2_support.c: (GtkSignalFunc)glide_gtk2_engine_hack_menu_shell_motion, ./engines/glide/src/glide_gtk2_support.c: (GtkSignalFunc)glide_gtk2_engine_hack_menu_shell_leave, ./engines/glide/src/glide_gtk2_support.c: (GtkSignalFunc)glide_gtk2_engine_hack_menu_shell_destroy, ./engines/glide/src/glide_gtk2_support.c: (GtkSignalFunc)glide_gtk2_engine_hack_menu_shell_style_set, ./engines/hc/src/hc_gtk2_support.c: (GtkSignalFunc)hc_gtk2_engine_hack_menu_shell_motion, ./engines/hc/src/hc_gtk2_support.c: (GtkSignalFunc)hc_gtk2_engine_hack_menu_shell_leave, ./engines/hc/src/hc_gtk2_support.c: (GtkSignalFunc)hc_gtk2_engine_hack_menu_shell_destroy, ./engines/hc/src/hc_gtk2_support.c: (GtkSignalFunc)hc_gtk2_engine_hack_menu_shell_style_set, ./engines/redmond/src/redmond_gtk2_misc.c: (GtkSignalFunc)redmond_gtk2_engine_hack_menu_shell_motion, ./engines/redmond/src/redmond_gtk2_misc.c: (GtkSignalFunc)redmond_gtk2_engine_hack_menu_shell_leave, ./engines/redmond/src/redmond_gtk2_misc.c: (GtkSignalFunc)redmond_gtk2_engine_hack_menu_shell_destroy, ./engines/redmond/src/redmond_gtk2_misc.c: (GtkSignalFunc)redmond_gtk2_engine_hack_menu_shell_style_set, ./test/torturetest.c: widgets[WIDGET_OPTION_MENU] = gtk_option_menu_new (); ./engines/mist/src/mist-style.c: gtk_style_get_font (style), http://library.gnome.org/devel/gtk/unstable/gtk-Types.html#GtkSignalFunc http://library.gnome.org/devel/gtk/unstable/GtkOptionMenu.html#gtk-option-menu-new http://library.gnome.org/devel/gtk/stable/GtkStyle.html#gtk-style-get-font
Hm, the gtk_option_menu_new is fine I think, it is just a test case. The other ones look easily fixable. It does not seem like gtk-engines is actually using much deprecated API, but in general it may be neccessary for us to do this so that deprecated widgets keep looking correct. There are some special cases for deprecated widgets in themes for example.
OK, I fixed the GtkSignalFunc cases. The other two cases are not fixable.
Sorry - reopening as there is also gdk_draw_string() still in the code: http://library.gnome.org/devel/gdk/stable/gdk-Drawing-Primitives.html#gdk-draw-string http://library.gnome.org/devel/gdk/unstable/gdk-Drawing-Primitives.html#gdk-draw-layout $:andre\> grep -r gdk_draw_string . ./engines/mist/src/mist-style.c: gdk_draw_string (window, http://library.gnome.org/devel/gtk/stable/GtkStyle.html#gtk-style-get-font http://www.mail-archive.com/gtk-app-devel-list@gnome.org/msg07191.html $:andre\> grep -r gtk_style_get_font . ./engines/mist/src/mist-style.c: gtk_style_get_font (style), $:andre\> grep -r gtk_option_menu_new . ./test/torturetest.c: widgets[WIDGET_OPTION_MENU] = gtk_option_menu_new (); Benjamin, can you specify what "not fixable" means? As long as gtk-engines compiles with the CFLAGS DGDK_PIXBUF_DISABLE_DEPRECATED DGDK_DISABLE_DEPRECATED DGTK_DISABLE_DEPRECATED as described in http://live.gnome.org/GnomeGoals/RemoveDeprecatedSymbols/GTK%2B I'm fine with that. :)
We *could* drop eg. the speical support for gdk_draw_string in mist, and add some special check to not run the option menu tests if the flags are set. However I think as libraries that directly supports/extends GTK+ and GTK+ using application gtk-engines is in a special situation where it may make sense to keep on supporting/using deprecated API until the API is actually dropped from GTK+ itself.
Thanks for explaining, makes a lot sense. So a patch that ifdef's for the GTK version would be accepted?
A patch that disables the calls if GTK_DISABLE_DEPRECATED is turned on would be acceptable, yes. I don't think any checks on the GTK+ version is needed, as gtk-engines already depends on 2.12.0.
OK, I have commited a fix to master. Note that it will print a couple of warnings to point out that some functionality is missing if compiled with DISABLE_DEPRECATED. If you find any issues, please open a new bug, or reopen this one.
Forgot to close the bug.
Thanks a lot, it's appreciated!
http://people.gnome.org/~fpeters/reports/299.html currently lists: GTK_WIDGET_HAS_DEFAULT, GTK_WIDGET_NO_WINDOW, GTK_WIDGET_STATE, gdk_draw_string, gtk_notebook_query_tab_label_packing, gtk_option_menu_new hence reopening. From a quick look at the code these issues seem to be valid. If some of them are false alarm please list them here so I can whitelist them from 299.html.
$:andre\> grep -r GTK_WIDGET_HAS_DEFAULT . ./engines/support/widget-information.h:#define GE_WIDGET_HAS_DEFAULT(object) ((object) && GE_IS_WIDGET(object) && GTK_WIDGET_HAS_DEFAULT(object)) $:andre\> grep -r GTK_WIDGET_NO_WINDOW . ./engines/clearlooks/src/clearlooks_style.c: if (GTK_WIDGET_NO_WINDOW (widget)) ./engines/clearlooks/src/support.c: stop |= !GTK_WIDGET_NO_WINDOW (parent); ./engines/thinice/src/thinice_theme_draw.c: widget && !GTK_WIDGET_NO_WINDOW(widget), ./engines/thinice/src/thinice_theme_draw.c: widget && !GTK_WIDGET_NO_WINDOW(widget), ./engines/thinice/src/thinice_theme_draw.c: widget && !GTK_WIDGET_NO_WINDOW(widget), ./engines/mist/src/mist-style.c: widget && !GTK_WIDGET_NO_WINDOW(widget), ./engines/mist/src/mist-style.c: widget && !GTK_WIDGET_NO_WINDOW(widget), ./engines/mist/src/mist-style.c: widget && !GTK_WIDGET_NO_WINDOW(widget), ./engines/hc/src/hc-style.c: widget && !GTK_WIDGET_NO_WINDOW (widget), ./engines/hc/src/hc-style.c: widget && !GTK_WIDGET_NO_WINDOW (widget), $:andre\> grep -r GTK_WIDGET_STATE . ./engines/crux/src/crux-draw.c: state_type = GTK_WIDGET_STATE (widget); ./engines/crux/src/crux-draw.c: state_type = GTK_WIDGET_STATE (entry); ./engines/clearlooks/src/clearlooks_style.c: state_type = GTK_WIDGET_STATE (widget); ./engines/clearlooks/src/clearlooks_style.c: state_type = GTK_WIDGET_STATE (widget); ./engines/clearlooks/src/support.c: state_type = GTK_WIDGET_STATE (parent); ./engines/glide/src/glide_gtk2_drawing.c: GtkStateType parent_state = widget ? GTK_WIDGET_STATE(widget) : GTK_STATE_NORMAL; ./engines/glide/src/glide_gtk2_support.c: (GTK_WIDGET_STATE(GTK_WIDGET(child->data)) != GTK_STATE_INSENSITIVE)) ./engines/glide/src/glide_gtk2_support.c: (GTK_WIDGET_STATE(GTK_WIDGET(child->data)) != GTK_STATE_INSENSITIVE)) ./engines/lua/src/lua_style.c: state_type = GTK_WIDGET_STATE (widget); ./engines/hc/src/hc_gtk2_support.c: (GTK_WIDGET_STATE(GTK_WIDGET(child->data)) != GTK_STATE_INSENSITIVE)) ./engines/hc/src/hc_gtk2_support.c: (GTK_WIDGET_STATE(GTK_WIDGET(child->data)) != GTK_STATE_INSENSITIVE)) ./engines/hc/src/hc-style.c: ge_gdk_color_to_cairo(&widget->parent->style->fg[GTK_WIDGET_STATE(widget)], &foreground); ./engines/redmond/src/redmond_gtk2_misc.c: (GTK_WIDGET_STATE(GTK_WIDGET(child->data)) != GTK_STATE_INSENSITIVE)) ./engines/redmond/src/redmond_gtk2_misc.c: (GTK_WIDGET_STATE(GTK_WIDGET(child->data)) != GTK_STATE_INSENSITIVE)) $:andre\> grep -r gdk_draw_string . ./engines/mist/src/mist-style.c: gdk_draw_string (window, $:andre\> grep -r gtk_notebook_query_tab_label_packing . ./engines/clearlooks/src/support.c: gtk_notebook_query_tab_label_packing (notebook, tab_child, $:andre\> grep -r gtk_option_menu_new . ./test/torturetest.c: widgets[WIDGET_OPTION_MENU] = gtk_option_menu_new ();
OK, some of the things are basically bug #612486. That is: * GTK_WIDGET_NO_WINDOW * GTK_WIDGET_HAS_DEFAULT * GTK_WIDGET_STATE The others are: * gdk_draw_string, which is already guarded by a DISABLE_DEPRECATED check * gtk_option_menu_new, which is already guarded by a DISABLE_DEPRECATED check * gtk_notebook_query_tab_label_packing So the gtk_notebook_query_tab_label_packing usage needs to be ported over to use the child properties. And the top three API usages depend on API from GTK+ 2.18 to be fixed.
This is also probably fixed in the gnome3 branch, and the fix for bug: https://bugzilla.gnome.org/show_bug.cgi?id=612486
Done in gtk-engines-2.90.0. If it breaks, you get to keep both pieces (the Crux engine didn't pass the torture test, but after looking for half-an-hour, I couldn't find out how to get it to tell me what failed).
Sorry, the whole torture thing worked good enough for me ... The best way is to attach GDB, which is possible with some environment variable, iirc. I'll look into what is going on there.
There is one issue left in the "gnome3" branch: ./engines/clearlooks/src/support.c: gtk_notebook_query_tab_label_packing (notebook, tab_child, Hence reopening. See http://library.gnome.org/devel/gtk/unstable/GtkNotebook.html#gtk-notebook-query-tab-label-packing
I took the freedom to commit the obvious patch for gtk_notebook_query_tab_label_packing