DEC
8
2011

The CTRL+M break-me option

A comment at the Calligra Words blog-entry asked about re-adding the CTRL+M "Hide Menubar" option back to Calligra Words (and the KDEPim-applications).

That is a *very* bad idea.

The "Hide Menubar" option, known from many KDE3 applications, is the typical example of a break-me option. The user can hit it by accident and will have a hard time to restore the previous state. More so if you add a 2-letter shortcut like CTRL+M to that option which is easy to hit by mistake and not so easy to discover if you did not know about it before.

Our rather detailed KDE Human Interface Guidelines even explicit name the problem:

Don't make the menubar 'hideable', users may not easily be able to make the menubar viewable again

As cool as it may to hide the applications menubar it can be a rather destructive action if done by accident without an easy way to undo and restore how it was before.

Ask yourself why you like to add such an action to your application? If the target is to just remove the menubar from all the applications cause you do not need or like them then why should that be done for every single application manually? Why should there not be a global way that allows to disable (or enable) them all in one go? Maybe even with a possibility to display the applications menubar somewhere else outside of the application like in the Panel (OSX-like) or only on hover or only with a certain shortcut like CTRL+M... This is what widget-styles like QtCurve or Bespin allow already today. If your preferred style (e.g. Oxygen) does not allow that yet, then you can still create a bug-report for that or provide a patch. In any case it will work out-of-the-box for all our applications and does not require you do add and later enable such an option at every single application.

Comments

When the standard "Hide Menubar" action is used for the first time, a dialog is displayed that explains what's going on.

If that is not enough for you, one could add a checkbox somewhere in System Settings that's disabled by default. Then "Hide Menubar" actions will only be visible when that checkbox is enabled.

I love "Hide Menubar", and I want it in every app.


By stefan majewsky at Thu, 12/08/2011 - 09:35

> I honestly don't see a problem
Well...

> When the standard "Hide Menubar" action is used
That is where the problem starts [1]

> I want it in every app.
That is where it ends [2]

> Then "Hide Menubar" actions will only be visible when that checkbox is enabled.
That goes into the right direction [3]

[1] Honestly that is not the case. Also the problem is not the action. The problem is the (non-)visibility in the UI including shortcut (that may there or not).

[2] Since not every app has it there is additional work needed on the application level to add it. That is *a problem* and the reason for the initial request linked above to add that. But more worse is that adding it means enabling it per default including the shortcut (see Konqueror or Dolphin). That is the second problem. Then we have the already named inconsistency that it's there in some applications and not in others what I would see as problem too and seems everybody, including yourself, agrees there. So, you *do* see the problem already :-)

[3] If such an option would be auto-handled, let's say by KXMLGui/KMainWindow, and either be there or not depending on whatever setting then we have a solution. In any case as application-developer I should not need to care about that. If that is the case then all problems are gone including requests to application-developers to add such a thing to there applications. it would be just there in the same way show/hide Window or show/hide/lock Toolbar are.

[1b] An extension not direct related and rather esoteric but well :-) You wrote "a dialog is displayed that explains what's going on". Personally I think modal messageboxes are one of the big mistakes of the 90'. Especially those ones asking "Are you sure you like to do what you like to do?". In my opinion an ideal desktop would not use any messageboxes. An ideal desktop should have a system-wide Undo-button that allows to undo deleting files, closing windows or changing settings. All actions done should be documented there and clicking undo would be going back in history. A real "time-machine" :)


By Sebastian Sauer at Thu, 12/08/2011 - 16:08

I agree that it is a dangerous shortcut to enable by default. Even with the initial warning dialog, the user can get caugth later on. So... dont put a default shortcut. If a user went so far as to manualy create a shortcut for it, one ca asume that said user knows what he's doing.

On the other hand, the application-specific setting *is* useful. It is not the same as having window-decoration support to hide the menu bar (or, god forbid, display it elsewhere).

I do not want a global setting: I only have a few applications where I want to always (terminal, text-editor) or sometimes (browser, document-viewer) hide the menu bar, either because I only use the keyboard or because screen space is at a premium. Sometimes applications will replace the hidden menu with an icon somewhere, that's nice too.

I do not mind wether the feature is implemented at the application, toolkit, or decorator layer. But it needs to be window-specific, easy to toggle, and broadly available. Until I see that in a quality toolkit/decorator implementation, I'll prefer to stick with a (inconsistent, work-duplicating) app-layer implementation.


By moltonel at Thu, 12/08/2011 - 10:40

Well, you need code in the applications themself where no code is needed. That means the solution to hide the Menubar could very well come from outside. It could be a Widget-style functionality with special options how the Menubar should be handled. I already named 3 different ways there; 1) shortcut to show/hide, 2) show it in the panel rather then in the mainwindow or 3) auto show/hide on hover. All that gives you power, flexibility for different solutions in a consistent way without putting any additional burden on the application-developers. If at all then it should be an action in KMainWindow/KPart::MainWindow/QMainWindow and as such available for *all* applications in a consistent way *without* any need for the application-developer to write one single additional line of code.

That is very much the same situation we have with Hide/Show/Lock Toolbars or with hide/show/minimize/maximize Window. That is consistent and no additional code is needed. It comes for free and gives you power for different solutions including a global enable/disable or just different ways to handle the Menubar.


By Sebastian Sauer at Thu, 12/08/2011 - 15:24

I think that having possibility to hide menubar on writing application is especially important. It's not unsual to write hours and hours without a break and that's when even little distractions get annoying. Menubar is the last thing that can't be manually hidden in Calligra Words. Also I don't necessarily want to hide all menubars everywhere not to mention that it's not currently possible and if I'm not mistaken it would be a hack if it were done by Oxygen, it would be nice but it wouldn't be a replacement for Ctrl+M beahvior. It should be obvious that different Apps have different uses for the menubar, Calligra Words is nice in a way that most of the functionality can be accessed elswhere.

On top of what Stefan said it could be possible to unbind it by default so it could still be done from one of the drop down menus and there would be no risk for accidental hiding. It's also usual behavior that one can enable the menubar from default context menu, easily discovereable. I guess it would also be possible to automatically add menu-icon to toolbar when menubar is hidden (similar to Dolphin).


By teho at Thu, 12/08/2011 - 10:42

I do not speak against adding such a possibility. In fact I made even a suggestion where such functionality could be. I speak against adding code to every single application out there to implement that.

Also it could allow to operate only on the current Window and hide/show the Menubar only there. So, it doesn't need to be global but it can be.

Yes, different apps have different uses for anything. In any case some of our applications come with such a hide/show menubar action while others don't. That is what I name inconsistent. And there is absolute no need for that nor is there a need to touch every single application out there to get such a feature.


By Sebastian Sauer at Thu, 12/08/2011 - 15:33

"The "Hide Menubar" option, known from many KDE3 applications, is the typical example of a break-me option. The user can hit it by accident and will have a hard time to restore the previous state."

There are no accidents if it is done correctly and not the way as it was done on KDE3.

1) Disable menubar hiding shortcut globally by default. NO ACCIDENTS. Those who want that feature, can assign a shortcut to that feature from systemsettings.

2) First time when menubar hiding function is used first time, show a pop-up window what just happened. That is already currently done. No reasons why person would not get it back if magically done it by accident.

3) Do not add by default a menubar hiding option to menubar itself (Settings > Hide menubar). As it can be very destructive. And reason for that is the action position, not the action itself. Example check how Dolphin does it. Click Settings, littlebit down and release and menubar is hided. So some people tought it is better to remove whole function instead just to rethink how it is hided/shown.

Menubars are very great way to add functions. Sidepanel is even better if there is just room. But just forcing to see a menubar even it is not used, is stupid, as user is allowed to hide toolbar but not menubar. When toolbar is used, it has usually a buttons to save, load, print, undo and redo, copy/cut/paste and so on. Those are most used actions for text editors and filemanagers.

Dolphin has great usability because menubar can be hided. Now it suffered as they made it so that if menubar is hided, there is permanent dropdown button on right end of toolbar copying Chrome style.
We already had a "Hide/Show menubar" action for toolbars what no one used. It was possible add to toolbar so person could just click it and menubar was visible and then again to hide it.

Some applications has done that when menubar is hided, mouse context menu gets "Show menubar" function. That is littlebit a hack.

But here are the differences:

http://imgur.com/a/vkHtB#0 vs http://imgur.com/a/vkHtB#2

And two example of very minimalistic and easy to use email windows for senior people who sends for specific people on their contact lists without subjects http://imgur.com/a/vkHtB#1 and http://imgur.com/a/vkHtB#3

Those are with KMail, but same applies to other KDEpim applications as well. They come much nicer and easier to use when not seeing a un-needed menubar or toolbar buttons (like what Dolphin forces).

And how about KIOSK modes? Wouldn't it be good to have some applications without menubar if there isn't anything to do?
People could configure their grandmothers or childs computers so that they are as easy to use as possible, only the needed functions available and visible for the user. Menubars can be scary ones or toolbars when there are lots of stuff (like Ribbon toolbar what Microsoft copied from Lotus and Macromedia).

With words, people wants always to have something like this? http://i.imgur.com/beU0f.png
Or how about http://i.imgur.com/MUJCB.png when statusbar is hided as well?

"Don't make the menubar 'hideable', users may not easily be able to make the menubar viewable again"

Then almost every application has braking that rule again. Only because users want to have slick and simple UI's to be possible achieved with configurations.

That rule should read:

"Don't make the menubar 'hideable' by default with shortcut or menu option, users may not easily be able to make the menubar viewable again"

It is totally different to give a possibility to hide menubar, than giving a possibility and making it easy to do by default.

What is wanted, is to have a Ctrl+M functionality, not even that shortcut. But that function. Shortcut unassigned (as it should be by default any application).

Last time, menu hiding function was not in kdelibs so every application needed to implement it separately.
The best thing to do, would be to add it to kdelibs and disable the shortcut by default.

So when user wants that feature to be usable, it is just one or two clicks from system settings to enable it and change Ctrl+M to other if wanted to all KDE applications.
There is now a global shortcut option for Ctrl+M in system setting, but not global option to turn or enable it from all applications.

And after all, how many persons really did mistakenly press Ctrl+M? It isn't easy shortcut by any meter. Easy ones are Ctrl+S, Ctrl+C, Ctrl+V. But even shortcuts like Ctrl+P or Ctrl+O gives huge challenge for many.

And if person press a shortcut and does not even notice that menubar is hided, it is more than just accident.

At least we dont need to remove Ctrl+Q shortcut as applications usually (usually... not always) asks does user want to quit the application or not.
At least they can reopen the file and application... But still it is annoing shortcut and should be removed forever... ;)

But even if the menubar hiding function and shortcut would be global one. It should not work globally for every application at once. Like user has five windows open and shows menubar, not all windows should show menubar, but just the one what is active.

Last one what I know what got back menubar hiding is Amarok. And it just makes Amarok even better than earlier.


By fri13 at Thu, 12/08/2011 - 15:55

There are no accidents if it is done correctly and not the way as it was done on KDE3.

There we absolute agree with each other :)

Dolphin has great usability because menubar can be hided.

And for example Firefox not? That brings us to the next topic: If done from outside like Canonical did with the global menubar and the patches for Qt and Gtk then you earn;
1. Consistency cause it works for all applications across desktops.
2. It works without additional code in the applications themself.
3. It allows different use-cases like such a global menubar in the panel and/or a shortcut that hides/shows the menubar in the application-window and/or on-hover showing/auto-hide.

The linked KMail screenshot is a perfect example for that. Why should it be needed to add special code in KMail itself to make that possible? Why should the action to do that be in the mainmenu and not for example accessible as global shortcut per application using those KGlobalShortcut-daemon?

And how about KIOSK modes?

Yes, the Kiosk admin-tool is a good point to bring in. It did allow to hide certain actions like the application-settings or the help-menu. That is fantastic (cudos to Waldo Bastian and SuSE for that). But it does not match 100% cause first it was trim-down. It's designed to only remove/disable functionality, to trim-down. Not to enable per default disabled functionality or to present that functionality in different ways (compare CTRL+M shortcut vs global-menu in the Panel vs on-hover).

"Don't make the menubar 'hideable', users may not easily be able to make the menubar viewable again"

Then almost every application has braking that rule again. Only because users want to have slick and simple UI's to be possible achieved with configurations.

Not exactly. You need to differ between making it possible to hide the menubar and to implement that in your application by e.g. adding a "Hide menubar" with a CTRL+M shortcut to your applications settings-menu.

Else you could easily argue that the global-menu in Panel implementation done by Canonical breaks the HIG. But it does not. The HIG is about applications and not about the desktop or services around it. The HIG does not cover the applications Window-decoration cause that's the job of the Window-manager. It is the job of the Window-manager do decide how the application-windows are handled (think of tiling or grouping). A good comparision is probably client-side window-decoration. That is a bad idea and Martin from KWin-fame wrote a very nice blog why. To a similar degree the same applies to menus. Let me re-pharse; "Consistent behavior between all applications no matter if it is a Qt or a GTK or $Toolkit application." In fact we have inconsistency not only between Toolkits but between KDE-applications already. That *is* a problem. It doesn't need to be one. Canonical showed with it's global-menubar implementation that hiding the menu in *all* application *without* any additional code needed in the applications themself is possible. So did others by implementing widget-styles like QtCurve or Bespin. Why should we not do the same for the desire to hide the menubar (but maybe do not display it in the panel but just hide/show it if e.g. a shortcut is pressed and maybe not for all windows/applications but only for the current one)? Why is it needed that application-developers reinvent that functionality, clutter there UI and bring inconsistency to there users? No matter what you will not find that shortcut or menu-item in Firefox. But Canonical's global-menu solution works with Firefox. If we implement that functionality outside of the applications then it could work for all applications with *no* additional work in the applications. I think that is a strong argument.

The best thing to do, would be to add it to kdelibs and disable the shortcut by default.

That sounds way better then what we had before or have now. In an ideal world we would reuse the same mechanism that is already working for Bespin, QtCurve and Canonical's global-menu...

And after all, how many persons really did mistakenly press Ctrl+M?

I could name you a few including myself. That shortcut and the one for sticky keys (which is thanksfull not enabled per default any longer in KDE4) where the main reasons for me rebooting or wipe my ~/.kde directory back then. Compared to CTRL+M the CTRL+P and CTRL+O shortcuts are not destructive. CTRL+Q or DEL can be. That is indeed a problem and APPLE+Q is the main reason for me why I think OSX is not usable (on the german keyboard it equals to the shortcut you press to get the @ sign).

At least we dont need to remove Ctrl+Q shortcut as applications usually (usually... not always) asks does user want to quit the application or not.

More important is that the application asks if unsaved work should be saved before. Closing an application by accident can annoy but destructive actions like losing my work (APPLE-Q) or making my UI unusable (CTRL+M) is a bit more then only annoying.

But even if the menubar hiding function and shortcut would be global one. It should not work globally for every application at once.

No, it doesn't need to. You could also make it working only for the current window/application. But the best on such a solution would be 1) no changes to applications needed, 2) works across all applications and even toolkits and 3) different implementations could be possible.


By Sebastian Sauer at Fri, 12/09/2011 - 09:00

Actually, in Firefox there *is* a context menu option to hide the menu bar (in the context menu of the tab bar and navigation bar).

However, if you hide the menu bar, it doesn't completely disappear, but rather becomes a single button in another bar that exists anyways (in Firefox, it's the tab bar - in Calligra it could be the tool bar).

Since there's precedent for the "menu bar as a single button in a place where it doesn't take away precious vertical space" concept in KDE already (Dolphin), maybe this could be a solution for menu bar "hiding" in Calligra?

As for complete hiding, the only way I think it should be done (if at all) is to list an action to do so in "System Settings > Standard Keyboard Shortcuts > Configuration of standard keybindings", but not assign CTRL+M (or any other shortcut) to it by default.


By smls at Fri, 12/09/2011 - 15:11

Well, the compressed menu is hard comparable with what CTRL+M does. The menu stays visible and reachable but is compressed to only one main item.

Also it's default on Firefox@Windows. Opera, Chrome and rekonq do the same btw and it's the default thing there too and in many cases switching back to the "full menu" isn't even supported.

There is additional work needed for that in the application to proper identify which actions are important and should be shown in that single menu and which not. In any case you will have a hard time to find a "Hide menubar CTRL+M" in that compressed menu what even confirms my point: that option should not be there in the first place. If you put it somewhere else (e.g. context-menu on right-click) then you will just not have the problem that activating the action means making it impossible to reach the action again to undo what you just did.

For Calligra we had that discussion (see http://blogs.kde.org/node/4405 ) but seems the more or less common agreement is that it brings even more inconsistency to your KDE desktop. Personally I would like to see that for more applications. It's the right thing to do and may it only cause it forces developers to re-think what actions are actually important enough for the user to put them into that single menu. I am pretty sure if that would happen the "Hide menubar CTRL+M" menu-item would be gone once and forever.

I absolute agree re standard keybindings. That would solve the problem.


By Sebastian Sauer at Mon, 12/12/2011 - 08:07

Pages