GNOME Bugzilla – Bug 674980
provide an app menu
Last modified: 2013-03-11 07:10:11 UTC
See https://live.gnome.org/GnomeGoals/PortToGMenu Suggested app menu format: New Window --- ✓ Toolbar ✓ Statusbar ✓ Side Panel ✓ Bottom Panel --- Preferences --- Help About gedit Quit
Hi Allan, yes this is something that we want to do, but it is far from trivial for two reasons: - it requires switching to GtkApplication (and we need to convert a lot of code to use that since for instance we have to handle "echo foo | gedit" - changing the menu api will break all plugins That said we need to do it. I am a bit surprised by seeing the toolbar, statusbar etc toggles in there, for two resons: 1 - they are definitely per window settings, for instance I find it quite common to have the sidepane shown in a window which holds my coding files (to see the source tree) while I have it hidden in the other random "doble-click-on-readme.txt" windows 2 - they are not so important to need to stand out so much
(In reply to comment #1) ... > I am a bit surprised by seeing the toolbar, statusbar etc toggles in there, for > two resons: > > 1 - they are definitely per window settings, for instance I find it quite > common to have the sidepane shown in a window which holds my coding files (to > see the source tree) while I have it hidden in the other random > "doble-click-on-readme.txt" windows If I hide the toolbar and then open a new window, that new window doesn't have a toolbar either. To me that makes it an application property rather than a window property. > 2 - they are not so important to need to stand out so much I'm mostly trying to be logically consistent - that should help people to understand what the new app menus are for.
(In reply to comment #2) > > 1 - they are definitely per window settings, for instance I find it quite > > common to have the sidepane shown in a window which holds my coding files (to > > see the source tree) while I have it hidden in the other random > > "doble-click-on-readme.txt" windows > > If I hide the toolbar and then open a new window, that new window doesn't have > a toolbar either. To me that makes it an application property rather than a > window property. > Well, the default is set based on the most current state, but I am still able to see it in a window and hide it in another, if I toggle it in the app menu I'd expect all windows to snap to the same state and that would be bad for the side pane and the bottom pane (toolbar and statusbar I do not particularly care)
I agree with pbor here, if I change something in a per app setting I would expect all the windows to change and get sync for that setting.
Please implement a fallback menu that makes sense for those who don't use GNOME Shell. The default fallback app menu is an usability disaster. It shouldn't be on ANY application.
Sure do not worry about that. First we still need to get gedit ported to GtkApplication.
I'd rather have the _Tools than the _View as proposed in the description. The views can all be made into short-cuts since they just toggle true-to-false, and two already are short-cuts. This could be the first GtkApplication that I've seen which had a recent-items in its GTK2-menu. Is this functionality preservable? It's the most important menu-functionality of gedit for me.
This bug can be closed.... gatlin, the original menu was not removed so no functionality is lost. You'll have to go to the application menu or Preferences, Help, and About, but that's all.
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.