Bug 90195 - Hiding the menu bar
Summary: Hiding the menu bar
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.5.0.0.alpha0+ Master
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
: 69959 (view as bug list)
Depends on:
Blocks: Main-Menu UNO-Command Notebookbar
  Show dependency treegraph
 
Reported: 2015-03-24 11:47 UTC by Yousuf Philips (jay)
Modified: 2017-04-22 11:47 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2015-03-24 11:47:40 UTC
It would be nice to be able to hide the menu bar, especially for users who never open it, as this provides more vertical space for the document and it would benefit in a touch screen mode.
Comment 1 Heiko Tietze 2015-03-24 12:22:40 UTC
In my opinion it's up to the OS or desktop environment how to handle main menu, window decoration, theming and colors (to make a Chuck Norris roundhouse kick). Run OS X or Gnome 3 if you want to hide or to place the menubar on top (KDE offers this option as well, of course). On the other hand, Firefox shoot forward...
Comment 2 V Stuart Foote 2015-03-24 12:45:24 UTC
@Jay,

Assume you mean a simple toggle to show or hide the main menu once you have launched the StartCenter or then a module. 

As distinct from full page mode, <Ctrl>+<Shift>+j, where both main menu and toolbars are hidden.

It would require a well publicized accelerator be assigned as a toggle, perhaps also something from the <Ctrl>+<Shift> block?

And, would have to adjust for menu functions on OS X, or other DE that want to control menus.
Comment 3 Yousuf Philips (jay) 2015-03-24 13:20:52 UTC
(In reply to Heiko Tietze from comment #1)
> In my opinion it's up to the OS or desktop environment how to handle main
> menu, window decoration, theming and colors (to make a Chuck Norris
> roundhouse kick).

Yes the OS/DE is the one that decides to show or merge it with an existing panel, but ultimately the user is in control of how LO looks. Dont see this any different then the user being able to show/hide a toolbar or change the document background color to another color.

(In reply to V Stuart Foote from comment #2)
> Assume you mean a simple toggle to show or hide the main menu once you have
> launched the StartCenter or then a module. 
>
> As distinct from full page mode, <Ctrl>+<Shift>+j, where both main menu and
> toolbars are hidden.

Yes a simple toggle when your in a module that takes the hiding idea from full page mode.

> It would require a well publicized accelerator be assigned as a toggle,
> perhaps also something from the <Ctrl>+<Shift> block?

Ideally we'd have a toolbar button to do this like what is available in MSO and Google Docs, but the menubar should be unhidden if the user does press a menubar shortcut like Alt+F.

> And, would have to adjust for menu functions on OS X, or other DE that want
> to control menus.

Yes this functionality wouldnt be used on OSs/DEs that hide the menu bar altogether.
Comment 4 Tomaz Vajngerl 2015-03-25 01:21:57 UTC
I have experimented with hiding the menu bar similar to how Firefox does it, by press & release of alt without any other key. I managed to get it work but then I didn't yet managed to force show the menu when you actually a menu accelerator (alt + registered key).
Comment 5 Jean-Baptiste Faure 2015-03-26 08:08:10 UTC
(In reply to Heiko Tietze from comment #1)
> In my opinion it's up to the OS or desktop environment how to handle main
> menu, window decoration, theming and colors (to make a Chuck Norris
> roundhouse kick). Run OS X or Gnome 3 if you want to hide or to place the
> menubar on top (KDE offers this option as well, of course). On the other
> hand, Firefox shoot forward...

I agree, but I am not sure if MS-Windows does know how to do that. And the larger part of the LibreOffice users has MS-Windows as OS/DE.

Best regards. JBF
Comment 6 Heiko Tietze 2015-03-26 08:37:29 UTC
(In reply to Jean-Baptiste Faure from comment #5)
> the larger part of the LibreOffice users has MS-Windows as OS/DE.

This is a pure guess. User Prompt's last survey that asks for demographical data too revealed this user structure:

Windows 	310 	21%
Linux (KDE) 	532 	36%
Linux (Gnome) 	525 	36%
Mac OS 	60 	4%
Other 	43 	3%

By the way: It's said AOO is more common in Windows and LO in Linux because of the distribution bundling. But I have no data on AOO.
Comment 7 Mart Tupman 2015-06-21 21:33:20 UTC
Hello to you all
I am working on a opensource software-suite that is meant to support music-educators in their daily teaching practice. LO (both Writer and Calc) will be part of it (as well as some others). The platform will be running under Windows, and portable. The option to hide the menubar is what I am looking for since long.

I was thinking of exact the same solution as Tomaz Vajngerl describes in comment #4.
I have seen the same idea in Notepad++, where you can select or unselect a setting in Preferences to "hide menu-bar (use Alt or F10 to toggle)"

I find requests to add this option to Ooo/LO since 2012, I really hope it will be picked up now. It would be super convenient  for the platform, since the interface consists of several panes/windows, each running an independant application. Hiding menubars would clean up the whole.
I am new to Bugzilla, don't understand exactly how it works. Can I help or be usefull in development/thinking on this issue in someway? Let me know.
Comment 8 Yousuf Philips (jay) 2015-06-24 22:34:11 UTC
@Tomaz: If you can submit your experimental code for hiding the menu bar and then bind it to Ctrl + Shift + K, that would be sufficient for this bug report.

I suggested being able to reactivate the menu bar with Alt + F, as on linux pressing just Alt doesnt activate the menu bar, atleast not on xfce and mate/gnome 2, but that works on windows.
Comment 9 Maxim Monastirsky 2015-07-27 05:04:42 UTC

*** This bug has been marked as a duplicate of bug 69959 ***
Comment 10 Tomaz Vajngerl 2015-07-27 08:00:44 UTC
(In reply to Yousuf (Jay) Philips from comment #8)
> @Tomaz: If you can submit your experimental code for hiding the menu bar and
> then bind it to Ctrl + Shift + K, that would be sufficient for this bug
> report.

Ah yes, sure can do that when I find the code again :P 
 
> I suggested being able to reactivate the menu bar with Alt + F, as on linux
> pressing just Alt doesnt activate the menu bar, atleast not on xfce and
> mate/gnome 2, but that works on windows.

The problem I have is exactly that - I can show the menu again on ALT + any other key, but ideally the menu should reappear only on if a menu accelerator is hit. I didn't found a solution for this - yet.
Comment 11 V Stuart Foote 2015-07-27 13:02:59 UTC
*** Bug 69959 has been marked as a duplicate of this bug. ***
Comment 12 Robinson Tryon (qubit) 2015-12-13 11:23:47 UTC Comment hidden (obsolete)
Comment 13 Robinson Tryon (qubit) 2016-08-25 04:44:44 UTC Comment hidden (obsolete)
Comment 14 Yousuf Philips (jay) 2016-10-05 14:11:11 UTC
Szymon create a .uno:Menubar command to toggle the visibility of the main menu for use with the notebookbar, which i believe uses the same code the full screen uno command.

https://gerrit.libreoffice.org/#/c/28044/

So what is remaining is

1) Assigning a shortcut
2) Auto unhiding it with the Alt key (tomaz's comment 4, comment 10 and bug 69959)
Comment 15 V Stuart Foote 2016-10-05 14:45:27 UTC
(In reply to Yousuf Philips (jay) from comment #14)
> Szymon create a .uno:Menubar command to toggle the visibility of the main
> menu for use with the notebookbar, which i believe uses the same code the
> full screen uno command.
> 
> https://gerrit.libreoffice.org/#/c/28044/
> 
> So what is remaining is
> 
> 1) Assigning a shortcut
> 2) Auto unhiding it with the Alt key (tomaz's comment 4, comment 10 and bug
> 69959)

Semantically the mini menu (black/white ODF icon) of the "Tabbed" layout of the Notbookbar names it a "Menubar"--but that is probably not ideal--it should just be "Menus". 

Pedro suggested in bug 69959 having a View -> Toolbars toggle for the Menu.

But it feels like the "Menus" control should be a direct toggle at top level of the View menu--not pushed down into the Toolbars split button list. 

Looking at the View menu (Writer) from a recent master, it is getting kind of crowded in the Toolbars section, so placing it there would be questionable.

Toolbar Layout
Toolbars
Notebookbar
Status Bar
Rulers
Scrollbars

Do we need a separator between Notebookbar and Status Bar?

So where to place the "Menus" entry, I'd say probably a top level toggle entry in the Sidebar and Navigator section of the View menu, linked to the .uno:Menubar command.
Comment 16 V Stuart Foote 2016-10-05 15:03:32 UTC
For a shortcut assignment, I'd suggest we simply continue to use the F10 key.

F10 now directs focus (cursor and program) to the Main menu, extending its behavior to now unhide the menu should be trivial. And would keep the UI consistent.
Comment 17 V Stuart Foote 2016-10-05 15:11:17 UTC
Hidding of the main Menus should probably not be by global shortcut. Just a View menu or Tools -> Options -> View configuration/Expert configuration. Or if hidden as controlled by UI as the Notebookbar does on the Tabbed view.

So use the F10 key would be to _only_ unhide the menu if hidden and not toggle it.
Comment 18 Yousuf Philips (jay) 2016-10-19 00:53:52 UTC
(In reply to V Stuart Foote from comment #15)
> Semantically the mini menu (black/white ODF icon) of the "Tabbed" layout of
> the Notbookbar names it a "Menubar"--but that is probably not ideal--it
> should just be "Menus". 

Both sound fine to me, though i would stick with Menubar as that is what it would be named as in the view menu, and not to be confused with context menu and various other popout menus.

> Pedro suggested in bug 69959 having a View -> Toolbars toggle for the Menu.
> 
> But it feels like the "Menus" control should be a direct toggle at top level
> of the View menu--not pushed down into the Toolbars split button list. 

Yes i agree as well.

You can find my reorganization of things in this patch.

https://gerrit.libreoffice.org/30028

(In reply to V Stuart Foote from comment #16)
> For a shortcut assignment, I'd suggest we simply continue to use the F10 key.
> 
> F10 now directs focus (cursor and program) to the Main menu, extending its
> behavior to now unhide the menu should be trivial. And would keep the UI
> consistent.

Sounds like a great idea to unhide the menu with f10.
Comment 19 V Stuart Foote 2017-02-21 23:23:26 UTC
So has the work needed for comment 14 been forgotten?

As we move the MUFFIN interface forward we need to resolve some of these issues before we can expose it as non-experimental.

Seems we are still going to need to assign a shortcut--F10 still makes the most sense--to toggle visibility of the main menu for use with the Notebook bar's tabbed layout, or other MUFFIN .UI interfaces that close it with the .uno:Menubar.  And as well configuring the <Alt> key for toggle to show the main menu for using its accelerators.
Comment 20 V Stuart Foote 2017-04-10 22:20:37 UTC
*** Bug 107058 has been marked as a duplicate of this bug. ***
Comment 21 Brian H 2017-04-21 07:18:17 UTC
This feature seems to be available from the notebookbar

[] -> Menubar

getting it back on screen is a bit clunky though. It would be great if there were some shortcut to bring it back instantaneously, like say the Alt key.

However, I'm not sure if that would work with the general direction Notebookbar. ie, if the Notebookbar is to be a full replacement for the menubar then the Notebookbar should naturally respond to the Alt-key. Notebookbar currently has no keyboard navigation.
Comment 22 Yousuf Philips (jay) 2017-04-21 22:45:25 UTC
This bug report was for the creation of the UNO command and thats been done, so lets close this and deal with other issues in separate bug reports. 

(In reply to V Stuart Foote from comment #16)
> F10 now directs focus (cursor and program) to the Main menu, extending its
> behavior to now unhide the menu should be trivial. And would keep the UI
> consistent.

I've filed bug 107343 to discuss this issue.

(In reply to Brian H from comment #21)
> However, I'm not sure if that would work with the general direction
> Notebookbar. ie, if the Notebookbar is to be a full replacement for the
> menubar then the Notebookbar should naturally respond to the Alt-key.
> Notebookbar currently has no keyboard navigation.

See bug 107344.