[Bug 620417] New: yast (gtk) button icons
http://bugzilla.novell.com/show_bug.cgi?id=620417 http://bugzilla.novell.com/show_bug.cgi?id=620417#c0 Summary: yast (gtk) button icons Classification: openSUSE Product: openSUSE 11.3 Version: RC 2 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME AssignedTo: bnc-team-gnome@forge.provo.novell.com ReportedBy: ke@novell.com QAContact: qa@suse.de CC: rpmcruz@alunos.dcc.fc.up.pt Found By: Documentation Blocker: --- We were wondering why there are not icons on the yast buttons (gtk ui). Ricardo enlighted us that yast inherits this feature from the GNOME default and he said on the yast-devel list: ============================================================================ The gtk plugin honors gnome's show-button-icons flag (which wasn't the case in 11.2), and now gnome (and opensuse along with it) defaults to FALSE. I dunno the rationale behind the new default, but it seems clear the gtk plugin should abide by it. It if is to be changed, I suggest we do at the gnome level. This setting can be changed by issuing: (for button and menu icons, respectively): gconftool-2 --set /desktop/gnome/interface/buttons_have_icons --type bool true gconftool-2 --set /desktop/gnome/interface/menus_have_icons --type bool true I personally find it much more comfortable to navigate through the menu when icons are enabled. Button icons I find are less visually useful (they are scarce and often their location already conveys their semantics), so it only adds to the overall UI pollution. ============================================================================== I like both gadgets, though ;) BTW, we should also check whether icons are enabled on XFCE and LXDE. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=620417
http://bugzilla.novell.com/show_bug.cgi?id=620417#c1
Ricardo Cruz
http://bugzilla.novell.com/show_bug.cgi?id=620417
http://bugzilla.novell.com/show_bug.cgi?id=620417#c2
Vincent Untz
http://bugzilla.novell.com/show_bug.cgi?id=620417
http://bugzilla.novell.com/show_bug.cgi?id=620417#c3
--- Comment #3 from Ricardo Cruz
We won't change the default here, I'm sorry: upstream has a good rationale for this, and I see no reason to diverge there.
What bothers me is that they changed the defaults _and_ (at the same time) got rid of the controls under Appearance that previously allowed users to change the behavior. Btw, if you've a pointer handy to a discussion about this, I'd be interested. I'm guessing it pretty much boils down to "Windows 7 shows no frigging icons." :P
However, it might make sense to force some icons to be visible in yast -- it really depends what they are.
Hmmm. We could honor gtk for ordinary icons (Ok, Cancel, etc), and show icons for less ordinary stuff (Up, Down buttons on a list) though they are rarely used. Here goes the list of the button icons. Tell me if you think some should always be visible. (If you can think of a yast tool that uses it, tell me, so we can contextualize it.) { "Apply", _("Apply"), GTK_STOCK_APPLY }, { "Accept", _("Accept"), GTK_STOCK_APPLY }, { "Install", _("Install"), GTK_STOCK_APPLY }, { "OK", _("OK"), GTK_STOCK_OK }, { "Cancel", _("Cancel"), GTK_STOCK_CANCEL }, { "Close", _("Close"), GTK_STOCK_CLOSE }, { "Yes", _("Yes"), GTK_STOCK_YES }, { "No", _("No"), GTK_STOCK_NO }, { "Add", _("Add"), GTK_STOCK_ADD }, { "Edit", _("Edit"), GTK_STOCK_EDIT }, { "Delete", _("Delete"), GTK_STOCK_DELETE }, { "Up", _("Up"), GTK_STOCK_GO_UP }, { "Down", _("Down"), GTK_STOCK_GO_DOWN }, { "Enable", _("Enable"), GTK_STOCK_YES }, { "Disable", _("Disable"), GTK_STOCK_NO }, { "Exit", _("Exit"), GTK_STOCK_QUIT }, (Buttons icons are also mapped by looking up the button role or wizard position, but those are pretty much a subset of these.) Enable/Disable is used for runlevel. Up/Down for bootloader. Initially, I'd agree to force visibility, but I'm not sure they're needed in either case given those buttons are very much isolated and visible as it is. They'd likely just feel out of place. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=620417
http://bugzilla.novell.com/show_bug.cgi?id=620417#c4
--- Comment #4 from Vincent Untz
(In reply to comment #2)
We won't change the default here, I'm sorry: upstream has a good rationale for this, and I see no reason to diverge there.
What bothers me is that they changed the defaults _and_ (at the same time) got rid of the controls under Appearance that previously allowed users to change the behavior.
Btw, if you've a pointer handy to a discussion about this, I'd be interested.
http://www.andreasn.se/blog/?p=103 is the announcement. There was discussion on the desktop-devel-list mailing list at the same time.
I'm guessing it pretty much boils down to "Windows 7 shows no frigging icons." :P
I doubt so -- it's actually the first time I hear this about Windows 7.
However, it might make sense to force some icons to be visible in yast -- it really depends what they are.
Hmmm. We could honor gtk for ordinary icons (Ok, Cancel, etc), and show icons for less ordinary stuff (Up, Down buttons on a list) though they are rarely used.
Here goes the list of the button icons. Tell me if you think some should always be visible. (If you can think of a yast tool that uses it, tell me, so we can contextualize it.)
{ "Apply", _("Apply"), GTK_STOCK_APPLY }, { "Accept", _("Accept"), GTK_STOCK_APPLY }, { "Install", _("Install"), GTK_STOCK_APPLY }, { "OK", _("OK"), GTK_STOCK_OK }, { "Cancel", _("Cancel"), GTK_STOCK_CANCEL }, { "Close", _("Close"), GTK_STOCK_CLOSE }, { "Yes", _("Yes"), GTK_STOCK_YES }, { "No", _("No"), GTK_STOCK_NO }, { "Add", _("Add"), GTK_STOCK_ADD }, { "Edit", _("Edit"), GTK_STOCK_EDIT }, { "Delete", _("Delete"), GTK_STOCK_DELETE }, { "Up", _("Up"), GTK_STOCK_GO_UP }, { "Down", _("Down"), GTK_STOCK_GO_DOWN }, { "Enable", _("Enable"), GTK_STOCK_YES }, { "Disable", _("Disable"), GTK_STOCK_NO }, { "Exit", _("Exit"), GTK_STOCK_QUIT },
(Buttons icons are also mapped by looking up the button role or wizard position, but those are pretty much a subset of these.)
Enable/Disable is used for runlevel. Up/Down for bootloader. Initially, I'd agree to force visibility, but I'm not sure they're needed in either case given those buttons are very much isolated and visible as it is. They'd likely just feel out of place.
Looking at this list, I feel none of them really need an icon. But I would argue it really depends on the interface in the end -- there's no automatic rule. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=620417
http://bugzilla.novell.com/show_bug.cgi?id=620417#c5
--- Comment #5 from Ricardo Cruz
I'm guessing it pretty much boils down to "Windows 7 shows no frigging icons." :P
I doubt so -- it's actually the first time I hear this about Windows 7.
Nothing surprising about it; no past Windows version used icons for buttons. What's surprising (and this was my point) is how Linux desktops have been blending more and more with OSX and Windows (especially the latter) as both of these desktops have become very stunning indeed. KDE 2.0 was a product quite apart from the hideous Windows 98, and was very visually competitive too. But interestingly, as Windows and OSX have been growing an individuality, KDE and Gnome feel more and more like copycats. For years, KDE and Gnome had been showing menu icons; the timing to get rid of them seems very odd if indeed it is uncorrelated with developments on the other line of the fire. Maybe it is unconscious, but according to your link it isn't even the case. This is the rationale offered by the original proposal to get rid of the icons: * Many (if not most) of the GNOME designers agree with this * OS X and Vista don't show them (except for special cases) * opening menus is much faster without them * the metaphors for the icons are often pretty useless * it is much more elegant and less visually cluttered without them * etc. Also see: * http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGu... As I read it: "Mac and Windows do it. [ insert a few rationalizations ]"
Looking at this list, I feel none of them really need an icon. But I would argue it really depends on the interface in the end -- there's no automatic rule.
We use an automatic rule because we don't have the benefit of specifying the button icons on a tool per tool basis. The less ordinary icons are used by only a couple of tools anyhow. I've already listed a couple; if anyone knows more cases, please list them, and we can then see what makes more sense in general. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=620417
http://bugzilla.novell.com/show_bug.cgi?id=620417#c6
--- Comment #6 from Federico Mena Quintero
http://bugzilla.novell.com/show_bug.cgi?id=620417
http://bugzilla.novell.com/show_bug.cgi?id=620417#c7
--- Comment #7 from Ricardo Cruz
I guess it's the kind of thing which you get used to. I don't know if there is hard data with evidence about icons in menus making things easier/harder to use.
I'd think any data on this would be pretty flimsy. Objective measurements and universal standards is the saint graal of social science. Speculating about this, I'm guessing that our brains have enough data (through the item position, or string length) to store a mental model of the menu. If you move to a new application however, you'll probably find yourself iterating the menu more closely to find, say, the printing icon. Anyhow each menu icons used its own color palette, and looked worlds apart, so the new default does look a bit more polished. It's just unfortunate that the menu-icons option was removed from the Appearances dialog at the same time that the default was changed. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=620417
http://bugzilla.novell.com/show_bug.cgi?id=620417#c8
--- Comment #8 from Ricardo Cruz
The story behind menu icons goes more or less like this:
[...]
Interesting story and it rings true. (Btw, why didn't gnome/gtk adopted the customizable toolbars too? :P) As you say, there's probably nothing new about Windows marking the pace, we just look at the past nostalgically. Don't think following Windows per se is a bad idea either: I like the mockup of Nautilus without the menubar a la Explorer, and I hope the windows taskbar will eventually feature windows/mac tab support. We should rely on first principles though to filter the gold from the dirt, and original arguments from the bug report did sound like rushed rationalizations heh (nobody complains we get rid of shades, shadows and whatever because that would make the UI "faster". at most, you fine tune the setting). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com