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 789004 - Standardize menu bar display behavior and support user-defined visibility preference
Standardize menu bar display behavior and support user-defined visibility pre...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkMenu
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-10-15 08:59 UTC by Simon Ochsenreither
Modified: 2018-05-02 19:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Simon Ochsenreither 2017-10-15 08:59:33 UTC
Actual behavior
---------------

Many Gtk and non-Gtk applications have a setting that allows users to hide the applications menu bar, for instance xfce4-terminal (check box in the menu bar), mousepad (context menu), Rhythmbox (xsettings/Gtk/ShellShowsMenubar), Firefox, Atom (Alt key) etc.

The annoyance I would like to address (at least for Gtk-based applications) is that every application seems to use different conventions.


Expected behavior
-----------------

There should be a setting that specifies whether in-app menu bars should be displayed and a standardized key binding/accelerator to temporarily show a hidden menu bar.


Proposal
--------

What I would like to do is to

a) have a user-wide setting that lets users defines whether they prefer showing or hiding
   the menu bar by default.

   Applications should be able to override this setting with an entry in their schema file.

   This setting only comes into effect in environments that don't provide a global menu bar
   (Windows, Xfce, Cinnamon, ...).

b) define a common key binding that temporarily displays a hidden menu bar
   (most applications seem to use Alt for this, Xfce seems to use F10).

In a sense, this is not introducing a new feature to Gtk, but standardizing an existing pattern and cutting down on the mess of every application coming up with their own ways and approaches to tackle this issue.

I would be happy to look into addressing this issue if someone can point me into the right direction.
Comment 1 GNOME Infrastructure Team 2018-05-02 19:15:45 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME'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.gnome.org/GNOME/gtk/issues/944.