hi, On Wed, Oct 9, 2013, at 10:45, Matthias Clasen wrote: > You are right that the functionality of the gtk-button-images and > gtk-menu-images settings was removed. They are only 'deprecated' insofar > as > programs that were using g_object_set to directly change these settings > on > the GtkSettings object will not fail to compile or run.
In-so-far as it is possible to use g_object_set() to change these settings manually, we still need to have code in the widgets themselves to support programs that do this. That means that we really have gained no advantage in terms of reduced complexity anywhere. However, from looking at the commits in question: menus: https://git.gnome.org/browse/gtk+/commit/?id=e8147d15f74e62047c84eb95e393449722198d89 buttons: https://git.gnome.org/browse/gtk+/commit/?id=65c31629c38b3b1f49fb6f3327dc28819ffe0657 it seems that this is not the case. Those commits remove code from GtkButton and GtkImageMenuItem to talk to the GtkSettings object, requiring you to use the "always-use-image" property on the GtkButton and the "always-show-image" property on the GtkMenuItem. In a way I'm conflicted about this. The simplifications to these widgets (although not substantial) have at least provided an actual reason for us to have removed this feature. It would have been utterly ridiculous and useless for us to have removed the binding glue for these options between XSETTINGS and GtkSettings if we still had the GtkSettings-specific behaviour in the widgets themselves (which is not the case). On the other hand, this really sucks if you're an app author and you just want your images back. If I read the code correctly then you cannot merely set the option on GtkSettings as you just suggested -- you have to set a property on every single affected widget. In any case, I'm not sure what the harm was of having this setting. I can appreciate that this stuff will all die when we have Wayland (and I'm happy for that) but removing this now (for a gain of -98 and -86 lines respectively to gtkimagemenuitem.c and gtkbutton.c) seems highly destructive for very little reduction in complexity. > As far as the functionality of those settings goes, we (the involved GTK+ > developers) have decided that we don't want to support this > functionality, > which makes it impossible for designers or even developers to know if > there > will be an icon at any place in the UI or not. This kind of variability > makes it much hard to design and develop user interfaces. For what it's worth, I agree that removing these icons in GNOME apps is a good idea, but I don't think the argument about predictability for designers and developers is a particularly good one. There's two reasons for that. The first is that, as far as GNOME goes, we do not expose a setting anywhere in our user interface for toggling this feature. If someone wants to mess around with XSETTINGS overrides or do something with the tweak tool, that's their business, and if they make their desktop ugly in doing so, then they get to own that. The second is that if an application author really really required no icons in their menus or buttons, even to the extent that they felt that they needed to override the user's settings, they could be the ones that manually override this at the GtkSettings level, forcing its value to FALSE. People keep raising this issue (both on list and on IRC) and I think there's a good reason for it. Cheers _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
