Re: Removal of icons in buttons/menus


On Tue, Oct 15, 2013, at 15:14, Olivier Brunel wrote:
I do not understand, however, why the entire GtkImageMenuItem widget was
deprecated, and not just what relates to those options - since using
icons in menus remain a very useful thing, and one used by many GTK apps
out there. It makes better UI/user experience as it allows to accomplish
certain tasks much easier/faster.

The commit message mentions using a GIO API, but that's certainly not a
"valid" replacement, since this is a completely different API and
doesn't get us an actual widget/menuitem we can use in a menu.
It looks like now every dev/app needs to re-implement this widget

I can give a bit of a background to the reasons here.

We make the distinction these days between "noun icons" and "verb
icons".  Noun icons are icons that go alongside menu items that are
nouns (things like bookmarks, applications in a list, disk devices,
etc.).  Verb icons are the old stock icons that we used to show beside
verbs (Save, Quit, Print, etc.).

Take a look at this page:

and take particular note of these paragraphs:

  "A menu item should have an icon before its text only where the item
  represents a dynamic object..."


  "Any icon that comes before a menu item’s text should be laid out as
  if it is the beginning of the text..."


  "In particular, icons of this sort should not go inside the margin..."

These "dynamic object" icons (that we call noun icons in GLib/Gtk) and
are the sort of icons created by the GIO API.  This is done in Gtk by
creating a GtkBox and packing the icon and label into it so you get the
effect mentioned in the spec above ("laid out as if is is the beginning
of the text", "not inside the margin").

GtkImageMenuItem puts its icon in the margin.  We don't ever want noun
icons to appear here.

I nearly added gtk_menu_item_set_icon() that would add a noun icon in
the proper place (ie: not in the margin) but implementing this proved to
be sort of complicated -- mostly owing to the fact that GtkMenuItem is a
container that can have arbitrary widgets added to it.  Dealing with all
of the possible combinations of things that could happen with icons,
images, labels, boxes and other arbitrary widgets got complicated fast
and I just gave up.  It was much easier to implement for
GtkModelMenuItem (which is how we get GMenu displayed in Gtk) because of
the limited scope and my total control over the widget, so I only did it

My thinking was that if you want noun icons, you can use GIO.  If you
want to continue using GtkImageMenuItem for verb icons (ie: things like
"Save", "Quit", etc... the old stock icons) then you could do so.  If
someone else wanted to add gtk_menu_item_set_icon() and take care of the
edge cases, we can still do that -- but this API should *only* be used
for noun icons, not to have an icon beside "Save" and "Quit".

Moreover, what's the justification for not only deprecated the while
widget, but breaking it - and therefore any & all GTK apps using it - at
the same time?

I don't agree with this having happened.  The deprecation is fine (and I
think we should drop it completely in Gtk 4) but breaking its
functionality during a stable cycle is not so cool.

I did what I did (adding support for noun icons) because we wanted to
use them from GNOME applications and applications written for Ubuntu and
this is what I was working on.  GNOME is also trying to move over to
using GMenu so it made sense to add the support for the noun icons
there.  GNOME turns off "verb icons" by default these days and I think
that makes sense for GNOME (and indeed, GMenu has no support for verb
icons).  That said, I still don't agree with (effectively) removing the
ability to have verb icons for people who still want them.

This is a widget that is only used when an icon should be present, since
that's the whole purpose of the widget. With GTK 3.10 this behavior, the
default/expected behavior since - again - that's the very reason to use
this widget, is now broken.

Note: this widget should only be used for verb icons.  These are no
longer of interest to GNOME developers, but I agree that others may find
this desirable...

Hope this provides some clarification.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]