! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Honor “Show icons in menu” setting regardless of GTK-wide menu icons setting
Status:
RESOLVED: MOVED
Severity:
enhancement
Product:
Xfce4-panel
Component:
Applications Menu

Comments

Description Raffaello D. Di Napoli 2012-10-10 03:37:12 CEST
Created attachment 4652 
Honor "Show icons in menu" preference even when menu icons are off for all GTK+ apps

I’ve been debating for a while whether to submit this trivial patch, because I’m not sure how it will be received. But I made my mind up now, so here it is.

I find the effect of the “Show icons in menu” checkbox to be not intuitive.
I don’t like icons all over the place in each program’s menu, but I do like icons in my Application Menu, so I thought that the intuitive thing to do was to disable menu icons for all GTK+ programs (via Settings Manager > Appearance) while keeping turned on the icons in the app menu only. But that didn’t work, because the GTK+ option overrides the app menu-specific option.

To scratch my own itch, I wrote this small patch, that gives full power to the “Show icons in menu” option. Users who do NOT want the icons in the app menu will still have an option to turn them off (just uncheck the box), while users who, like me, want icons to show up in that menu only, will now have a way.

Would you please consider this patch? It’s easy, clean, user-fiendly(er) and whatnot :)
Comment 1 Raphael Groner 2012-11-04 17:18:11 CET
As it turns out, showing icons or not should be a general thing of the applied theme. It's too confusing for the user when icons (and mouse cursor and the window decorations) can be configured individually at different places.

See https://bugzilla.redhat.com/show_bug.cgi?id=863337#c3
and https://bugzilla.redhat.com/show_bug.cgi?id=863337#c7

Other ideas:
The checkbox for "Show icons" in the plugin's dialog should be disabled, grayed or at least with a nice tooltip saying that appearance settings are globally applied. I hope that should be more user friendly.
I don't see much sense in having icons in the desktop menu, but not in the plugin. So we should think about removing the specific checkbox from the plugin's dialog.

Already suggested downstream: 
https://bugzilla.redhat.com/show_bug.cgi?id=863337#c8
Comment 2 Raffaello D. Di Napoli 2012-11-04 18:14:44 CET
(In reply to comment #1)
> As it turns out, showing icons or not should be a general thing of the
> applied theme. It's too confusing for the user when icons (and mouse cursor
> and the window decorations) can be configured individually at different
> places.
> 
> See https://bugzilla.redhat.com/show_bug.cgi?id=863337#c3
> and https://bugzilla.redhat.com/show_bug.cgi?id=863337#c7

It doesn’t look like the original subject of that bug has anything to do with this bug. This bug is about fixing this inconsistency in displaying menu icons in the menu applet:

 Applet > | Enabled | Disabled
Global    /---------+---------
---v-----/
Enabled  |    On        Off
Disabled |    Off       Off

An application-specific setting should override a global setting, while in this case it doesn’t; there’s no way to enable the menu icons in the applet if they are globally disabled.

Let’s examine my proposal:

 Applet > | Enabled | Disabled
Global    /---------+---------
---v-----/
Enabled  |    On        Off
Disabled |   *On*       Off

The use-case here would be an user decides she don’t want menu icons any more, so she disables them globally. Upon opening the applet menu, one of three things could happen:

- She notices that the icons are still there, and quickly figures that they have to be an applet-specific setting, so with a few mouse clicks she disables them;

- She notices that the icons are still there, and thinks that it makes sense because that menu is rather unique (after all, we’re still mimicking M$’s paradigm from 17 years ago);

- She doesn’t notice that the icons are still there.

In the first two cases, the user is assumed to be somewhat experienced; in the last case, the user is assumed to be a novice. In all three cases, the user experience is unimpacted, because it was possible to achieve exactly what the user wanted.


(In reply to comment #1)
> Other ideas:
> The checkbox for "Show icons" in the plugin's dialog should be disabled,
> grayed or at least with a nice tooltip saying that appearance settings are
> globally applied. I hope that should be more user friendly.
> I don't see much sense in having icons in the desktop menu, but not in the
> plugin. So we should think about removing the specific checkbox from the
> plugin's dialog.
> 
> Already suggested downstream: 
> https://bugzilla.redhat.com/show_bug.cgi?id=863337#c8

This makes me think of GNOME’s approach: remove all options in the name of so-called user-fiendlyness. This is one of the main reasons more and more people are running away from GNOME to Xfce. Disallowing customization is NOT user-friendly.
Comment 3 Raffaello D. Di Napoli 2015-02-19 14:02:36 CET
Hmmm... bump?

I still believe this patch is relevant. Every shell out there has icons in their “main” menu regardless of whether icons are displayed in menus in general.

The Red Hat bug linked by Raphael doesn’t seem really relevant, as it’s about xfsettingsd not behaving correctly. Here I’m talking about allowing users to display icons in the only “special” menu in the whole desktop metaphor, even if menu icons are globally turned off.
Comment 4 Git Bot editbugs 2020-05-28 01:43:22 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/42.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #9365

Reported by:
Raffaello D. Di Napoli
Reported on: 2012-10-10
Last modified on: 2020-05-28

People

Assignee:
Nick Schermer
CC List:
0 users

Version

Version:
4.10.0

Attachments

Additional information