Make the application menu-bar hideable

[Wallacoloo]

This is inspired by an old suggestion by @tresf to optimize the toolbar space: #387 and also by the way Firefox deals with the application menubar.

The gist is that by pressing Alt (and only alt - any more complex key release event is ignored, which allows for shortcuts to still use alt), the visibility of the menu bar (the bar at the top with file, edit, view submenus, etc) is toggled. It still supports the previous shortcuts of Alt+E to open the Edit menu, etc. Furthermore, clicking anywhere outside of the menu bar will cause it to automatically be hidden.

In order to avoid any confusion until we implement something like a chrome menu button to go with it, this setting has to be explicitly enabled under the settings menu.

Here's a short gif, but it still won't explain the functionality as much as a test-drive since you can't tell when I press alt, or click, etc.

Would appreciate some testing with this if possible (don't forget to enable the behavior under settings).

[tresf]

Very nice.

I'd like to add that we have to be careful not to hide menu settings behind shortcuts with no mouse equivalent. What #387 proposes is that the menu is behind a toggle button. I'm not sure I see such a toggle button in the animation above.

Coders are a rare breed of people who can live with terminals and editors and exist in a pure shortcut driven world. For the rest of the population, we need to make a way to hunt and find actions with the mouse cursor. :)

In the case of Firefox and Chrome non-common items are hidden in a toggle menu, but a large indicator button exists to get to these items. I think whatever we decide on should adhere to the same standard.

[Wallacoloo]

@tresf that's the primary reason why this is disabled by default. I figure once we add something like a Chrome menu button, it should be easy for a user to do everything by mouse or for them to reach the setting menu if they forgot how to enable the menu bar.

Until then, I could make the menu bar appear whenever the mouse is near the top of the window. In my experience (cough Unity cough) that's almost always horribly disruptive to workflow, so I would be incredibly hesitant to take that route.

I could also make the file menu visible on program start, no matter what the hideable menu bar setting is. This way a user could still get to the settings box if they don't know the shortcut. This might actually be best since it's common to open LMMS and immediately go to the file menu to open a recent project. OTOH, it does feel weird when the first time you click inside LMMS the menubar disappears & everything shifts up 30 pixels. It's probably worth the trade-off though.

Opinions?

[tresf]

I still vote we rid the legacy idea of File, Edit, View and make the popup-menu a permanent space saving change. This seems like an interim and rather obscure fix to a relatively simple problem.

That said, any efforts to save real estate are bound to stir excitement. :)

[Wallacoloo]

In the case of Firefox and Chrome non-common items are hidden in a toggle menu, but a large indicator button exists to get to these items. I think whatever we decide on should adhere to the same standard.

This isn't actually 100% true. The toggle menu hidden behind the large indicator button only shows some actions like "Save page", "new window", "zoom", etc. But it lacks less common actions that can only be reached through the application menu bar, e.g. "View -> Character encoding". And the menu bar behaves almost exactly as I implemented in this branch - it's permanently enabled by default, but can be configured as hideable in the settings manager. So there isn't quite a standard here. Not sure how Chrome does things.

[tresf]

You are right.... Firefox decided to really confuse users and take the "easy buttons" approach.

Chrome hasn't done this yet.

Perhaps this is what people want, but I'm not a huge fan, personally.

[Wallacoloo]

I still vote we rid the legacy idea of File, Edit, View and make the popup-menu a permanent space saving change. This seems like an interim and rather obscure fix to a relatively simple problem.

I'm not certain I completely agree with this. Application menus are very standard. So much so that some OSes already implement them in a way that costs zero space (e.g. OS X placed the application menu in the main OS menu bar at the top that displays things like the current time, log-out, etc, last time I used it. Some Linux window managers do the same). I'm not sure if Qt makes use of these menus by default. If it doesn't, then I'd have little problems in getting rid of the file/edit/view menu so long as the replacement is suitable. But if it does, I support using both functionalities on the OSes where menu bars have no space cost.

Anyway, I suppose we'll have to wait a few days for people to chime in and see what the consensus is on this PR. Since I'm accustomed to this behavior, I hadn't thought to question if others might find it obscure.

[tresf]

As far as QT + integrated menu bars, it has compatibility issues with MDI layouts on Ubuntu, so we had to disable the integration w/ Unity via:

https://github.com/LMMS/lmms/blob/master/data/lmms.desktop#L9

I have my personal opinions about the effectiveness of how Ubuntu decided to tackle this but I'll save that for another time and place. :)

[Wallacoloo]

It's been a year since I tried Unity. The problem I actually had with it was that the mouse edge-detection algorithm didn't work on my hardware (which seems odd, as I would expect such behavior to be hardware/driver-agnostic), so I could never actually expand the application menu.

[curlymorphic]

While Testing It seem to work as per the description. The only thing I picked up on was the text in the settings box says not .

[Wallacoloo]

@curlymorphic The settings description now reads "Auto-hide the application menu bar (toggle visibility with )". Hopefully that's better. Anything longer wont show properly in the settings dialog, and I can't come up with a more descriptive, non-ambiguous description that fits in that length.

[curlymorphic]

@Wallacoloo Sorry, looks like I got distracted earlier. I was referring to the incorrect key used in the description, but looks like I never got round to saying that , my fault.

[Wallacoloo]

Smacks self in face. I can't believe I missed that... (fixed now though)

[tresf]

Tested on OSX and this doesn't seem to have any negative side-effects, but I would prefer that the checkbox is hidden completely from the Settings Dialog on Mac as the integrated menu bar isn't impacted by this change making it irrelevant and misleading for that platform.

[Wallacoloo]

@tresf would you prefer I just add

#ifndef MAC_OS
[add option to settings dialog]

to the settings dialog? Or should I make that:

#ifdef SHOW_AUTOHIDE_APPMENU_OPTION
[add option to settings dialog]

and calculate SHOW_AUTOHIDE_APPMENU_OPTION in the CMakeLists.txt?

[Wallacoloo]

Rebased. However, it should be noted that at some point, shortcuts like "Ctrl+s", etc stopped working when the menu is hidden. Please hold off on merging this until I fix that.

[tresf]

#ifndef MAC_OS
[add option to settings dialog]

👍

[softrabbit]

Unfortunately the PianoRoll seems to catch Alt if it has focus. Used for at least Shift-Alt-Left/Rightcombos to move notes in small steps and Alt-Left/Right to change pattern.

[tresf]

@Wallacoloo can we close this topic and reopen at a later time if needed? It seems like there isn't a huge demand for it currently and it has some drawbacks in its current implementation.

[Wallacoloo]

@tresf agreed.