After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 592756 - remove interface tab
remove interface tab
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: [obsolete] Appearance
git master
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-22 22:29 UTC by William Jon McCann
Modified: 2011-01-31 17:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (22.54 KB, patch)
2009-08-22 22:39 UTC, William Jon McCann
none Details | Review
updated patch (32.07 KB, patch)
2009-08-23 00:44 UTC, William Jon McCann
committed Details | Review

Description William Jon McCann 2009-08-22 22:29:25 UTC
Discussed many times.  We should remove the interface tab.  Basically everthing there is a user experience design cop-out.  It only belongs in a tweak UI tool - but only if someone cares enough to write one.
Comment 1 William Jon McCann 2009-08-22 22:39:06 UTC
Created attachment 141459 [details] [review]
patch
Comment 2 William Jon McCann 2009-08-23 00:44:22 UTC
Created attachment 141463 [details] [review]
updated patch

Remove all of it.
Comment 3 Guillaume Desmottes 2009-09-16 10:23:34 UTC
No we shouldn't. We can't remove icons from menus and then let no "easy" way for users to revert to the old behaviour if they want to.
Comment 4 Xavier Claessens 2009-09-16 10:43:27 UTC
I agree with Guillaume. See bug #595341
Comment 5 Andreas Nilsson 2009-11-04 01:01:23 UTC
How do you feel about the others?

I find "Editable menu shortcuts" 10 times crazier than setting the kind of toolbar type (but I wonder if all apps having the same style on the toolbar always make sense).
Comment 6 Thomas Wood 2009-11-09 20:45:29 UTC
Comment on attachment 141463 [details] [review]
updated patch

I agree with McCann, if someone wants to tweak their settings in such a way, then it should be done through an appropriate "tweaks" application. The interface tab does not contain options that are of interest to the majority of users.

I've pushed the patch to master.
Comment 7 Xavier Claessens 2009-11-10 07:35:13 UTC
If the default was sane I would 100% agree... but with the new default introduced in GNOME 2.28 I strongly disagree with removing the interface tab. We *really* need an option to get back an usable desktop. I mean: Text under icon in toolbar + icons on buttons for dialogs + icons in menu.

I also agree that icons are sometimes abused in application. That's totally true. But removing them all because some are useless is incredibly stupid. It's throwing out the baby with the bath water.

Please explain me what is the purpose of the whole gnome-appearance-properties application if it is not a "tweaks" application? Really, I don't understand!
Comment 8 Vish 2010-02-07 07:52:35 UTC
When the icons were removed from the menus ,it was mentioned that , "For users who care, they could change the settings from the interface tab".
Well, a lot of users used this tab to switch the prefs. 
Now we are removing this option too, and forcing users to dig deeper? 
[if i was a conspiracy theorist I'd say this is being done just to force the new default ;)  ]

Another setting , Toolbar layout. 
[Is the "text beside the icons" the default gnome toolbar layout? It is in Ubuntu]

The "text beside the icons" is an awkward setting , there is no logical order/design/meaning to this setting. [Other than conserving vertical space]
The meaning of some icons is not clear and they dont have text , while easily comparable icons like the navigation forward has a label.
This setting is just an awkward interruption of icons by the text at random.

A setting of text below icons or only Icons is a much saner default. [this may very well be a separate bug]

Why i mention this here is , these settings are basic and easy for an average user to switch, Rather than having to dig deeper or wait for a tweak UI tool to be written.
Comment 10 André Klapper 2010-02-09 10:10:10 UTC
Mark: Completely unrelated, non-technical comment that adds no value to this report. Please go somewhere else. Bugzilla is not a forum. Thanks.
Comment 12 Olav Vitters 2010-02-21 04:47:28 UTC
Note that disagreeing is fine as long as it follows the Code of Conduct. See http://live.gnome.org/CodeOfConduct. I have a very low tolerance if this is not followed. The Code of Conduct basically mentions: respectful, considerate, patient, assume people mean well, be concise.

Note that the Code of Conduct also encourages "be concise". Meaning: try to keep it short and do not repeat previous comments.

Thanks


PS: To make it very clear: I am one of the admins of GNOME Bugzilla.
Comment 13 robin wheeler 2010-02-21 05:13:50 UTC
Should I file a bug that on a clean install there are still some icons in the menu should they not now all be gone?
Comment 14 David Muir 2010-02-24 11:51:44 UTC
Agree with Xavier. gnome-appearance-properties is a "tweak" application. So you're effectively removing an option from the tweak application to be put into another tweak application to tweak the original tweak application to let us tweak the interface.... makes sense to me.

The only tab that seems out of place to me is the Background tab. Everything else is a tweak.
Comment 15 Christoph Langner 2010-02-24 18:32:30 UTC
And what about the possibility to change the way text is displayed besides icons? I usually change here the settings from "Text besides icons" to "Icons only", since I know the programs I use. I you remove the whole tab, this option is gone too!
Comment 16 Matthew Paul Thomas (mpt) 2010-02-25 19:09:50 UTC
robin, thanks for your observation, but what you see is correct: some menu items are supposed to still have icons. The difference is that now when an item doesn't have an icon, it's a design decision, whereas before it was because no artist had managed to think of an appropriate metaphor.

Now, we have not communicated this icon thing nearly as well as we could have (which may be why Xavier talks about "removing them all", for example). This week I will submit a patch to the HIG to make the guidelines official on which items should have icons and which shouldn't.

Christoph, you got part-way to the essential point about toolbar labels: Whether a toolbar should have icons/text/both depends much more on the particular program than it does on the user session as a whole. If it's a program people rarely become expert at (e.g. a greeting card maker), it's more likely to need labelled toolbar buttons. If it's a program where screen real estate is at a premium (e.g. a help viewer or Web browser), it's more likely to warrant an icon-only toolbar by default. If it's a program where the buttons are few and obvious (e.g. a help viewer or movie player), it's less likely to need text on its buttons, and so on. This doesn't mean it should never be configurable! But in programs where it should be configurable, *the program itself* should provide that interface -- as Epiphany and Geany already do, for example. Making it customizable in the program itself is both more flexible and easier to find. It also eliminates the weirdness currently shown in Epiphany's Customize Toolbars window, where there's a "Default" choice that does exactly the same as one of the other choices.

"Editable menu shortcut keys" probably would make more sense as part of the "Keyboard Shortcuts" settings, maybe as a more guided action ("ok, now select the menu item you want to change the key combo for").
Comment 17 Maciej Katafiasz 2010-02-25 19:14:45 UTC
Oh man, again? The default is already there, and it omits icons. The appearance panel is, by definition, visited by people intent on changing the appearance. Please don't make it any harder to revert an extremely controversial decision. That's changing it from "default is this way" to "you WILL like it because I said so". While we're at it, why not remove the ability to change themes? After all, the defaults ought to be good enough for everyone.
Comment 18 Maciej Katafiasz 2010-02-25 19:20:14 UTC
comment #16: the fact that "Default" corresponds to one of the choices is a given, as one of the existing options has to be default, whether it's picked by the app's designer or from the global settings. So that in itself is not particularly surprising. That said, it's probably the least useful setting of all. But on the other hand, if we agree it makes no sense to provide it globally, it should be mandatory for all apps with toolbars to provide an option to do that.
Comment 20 Olav Vitters 2010-02-25 22:19:09 UTC
Removing the troll. And no, that is not Maciej. As per comment 12: Disagreeing is fine, trolling: bye.
Comment 21 Daniel Ellis 2010-03-09 22:24:11 UTC
Apologies in advance if my comment is naive, as I do not have any understanding of the innards of Gnome.

However, I understand it to be that an icon in an application can be defined as optional or mandatory.  Meaning that the developer is supposed to decide if the icon is specifically required (e.g. the bookmarks menu in Firefox) or should be optionally displayed.

If Gnome is to include the ability to define optional icons, surely it should be a configurable option for the user.  Otherwise what is the point of the developers defining the optional icons?

This type of setting is not a tweak such as "tcp window size" or other potentially dangerous configuration option, but in my opinion, a genuine user preference.
Comment 22 Krzysztof Kosiński 2010-03-21 20:37:01 UTC
Removing that tab completely was a bad move. Only one item was not related to appearance (editable keyboard shortcuts). That item should have been removed. Others were purely about appearance, for example menu and dialog buttons and whether text is shown on toolbars.

I also don't understand how "Basically everything there is a user experience design cop-out". For an OSX user, removing icons from the menu might improve the "user experience", but for me it degrades it; which is aggravated by the fact that I now need to search for a 3rd party application to change this. I don't see how removing a legitimate option just because someone feels it doesn't belong in the dialog could improve the user experience.

Instead of checking something in a dialog, I now need to find a working "tweak UI" application that might or might not work, and might or might not contain malware. The more options you remove, the bigger is the risk that someone starts to distribute malware masqueraded as an UI tweaking tool.
Comment 23 Morpheus 2010-04-11 13:39:28 UTC
> If the default was sane I would 100% agree... but with the new default
> introduced in GNOME 2.28 I strongly disagree with removing the interface tab.
> We *really* need an option to get back an usable desktop. I mean: Text under
> icon in toolbar + icons on buttons for dialogs + icons in menu.
> 
> Please explain me what is the purpose of the whole gnome-appearance-properties
> application if it is not a "tweaks" application? Really, I don't understand!

I strongly agree with that.

I like to have text+icons on menu because with it I can find with a quick look the option or button I need, or, when I don't remember the exactly icon, I can read their labels; now, to restore previous appearance I had to investigate where the option is in gconf.

I have enough knowledge about gnome structure to know where I can change this option, but others users may not have it; I think that's a bad idea to remove that tab.
Comment 24 Maxim Cournoyer 2010-04-24 17:48:16 UTC
@William Jon McCann
"Discussed many times.  We should remove the interface tab.  Basically everthing
there is a user experience design cop-out."

This UI choice (of removing the interface tab) seems to completely prevent the customization of shortcuts in Nautilus. I used this extensively to assign custom keyboard shortcuts to Nautilus Action scripts (they can be start in Nautilus menu File->Scripts->...). For example, pushing F4 ran a script which started a terminal in the currently browsed folder. Also, I Ctrl-E was set to edit files with Emacs even when the file had the executable bit set. Just to name a few useful applications. I find it hard to believe developers themselves don't need this functionality.

Now I do not see a way to customize Nautilus shortcuts anymore. I might agree that the Interface tab did not belong in the "Appearence" view, but I strongly disagree of removing it while nothing can replace its powerful (and unique?) feature adequately.

"- but only if someone cares enough to write one."
Wouldn't it be simpler to just keep the code that was implementing the feature hidden from the UI but available in gconf-editor? This seems to be the gnome-way for power user settings.
Comment 25 Arand 2010-04-24 19:42:26 UTC
> Wouldn't it be simpler to just keep the code that was implementing the feature
> hidden from the UI but available in gconf-editor? This seems to be the
> gnome-way for power user settings.

The gconf keys in /desktop/gnome/interface/* still exist as part of libgnome
And I sure hope that isn't going anywhere in a hurry.

As for the removal, I can agree on the interface tab being not completely straightforward.
But in my mind the right fix would be to add a line or two in explanation, or an informative tooltip. It's not as if the interface tab in itself lacks space, or that the options are inherently cruft.
Comment 26 Maxim Cournoyer 2010-04-24 19:51:45 UTC
@Arand : Thank you for this information! The "can_change_accels" is still there. I'm a bit relieved ;).
Comment 27 Gonzalo Aguilar Delgado 2010-08-23 09:45:42 UTC
Great!

I'm testing 10.04 and not only icons dissapeared. But also the menu! I cannot program I cannot work nor even open a file. But because you removed the interface panel in the menu I cannnot restore it...

Man... You should keep this and don't do like sony. Don't remove features, please!


Thank you.
Comment 28 Adi Roiban 2010-12-12 22:53:19 UTC
I think that a documentation patch is also needed.
The current documentation still mention the 'Interface' tab from the Appearance 
http://library.gnome.org/users/user-guide/2.32/prefs-appearance.html.en#prefs-menustoolbars

Cheers
Comment 29 André Klapper 2010-12-13 11:42:03 UTC
(In reply to comment #28)
> I think that a documentation patch is also needed.

Please file a bug at https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-user-docs
Comment 30 Adi Roiban 2011-01-31 17:23:29 UTC
Reported as bug #641053

Cheers,
Comment 31 William Jon McCann 2011-01-31 17:55:33 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.