43

My idea: Remove the menubar, replace it with a button in the titlebar


When u click on the button, a menu with the old content is shown.

(Got inspired by the firefox 4 -mockups)

I like this idea, however it seems like it would be difficult to implement due to constraints between the window-manager communicating with the programs themselves. In addition, Gnome, Firefoxx/thunderbird and KDE all use different methods on controlling the toolbar - if we did integrate KDE programs into this, firefox, gnome apps and others would need to be integrated manually somehow.

How would that work with docked windows aswell?

If anything like this were to come to light, I think I would prefer it being an option on simply showing/hiding the bar, instead of removing it completely.

I do not like this idea. Here's why:

KDE should not only be a desktop for professionals that find a menu even when it is hidden somewhere in invisible bars that appear when you shoot yourself in the foot.

KDE should be accessible to everyone that intends to use it and that means, solutions to his questions should be presented visible - and solutions that is menu options in the first place.

This type of menus is already being adopted on windows platform, it's used in Office 2010, Opera alpha (you can switch to old menu here) and upcoming Firefox as we can see.

It's not ordinary list type menu, it's more like start page or start menu, with wider space for options arrangement ( in Office case it takes size of whole app )

And I would dare to say that it's much easier to use for so called non-professionals, as more options is visible instantly with big icons near them usually.

Also, it saves some space, which is useful in some cases.

@incredion
Not looking like windows is not the same as being incredibly hard to use. Most users rarely need to use the menubar at all anyway, which makes the current solution a huge waste of space.

You can hide/unhide the menubar with Ctrl+M.
The usefulness of the menubar depends on the app considered. Maybe a browser do not need a menubar and in fact rekonq hide it in a small button, but hide the menubar in a wordprocessor and tell someone who never used that app to figure out how to write something and you will have an unhappy user. IMO, not considering some particular apps like rekonq, the ability to hide the menubar must be an advanced option only and current keyboard shortcut approach is perfect for me.

@RGB
It's not like there is much of a learning curve or even any more clicks required. Alot of users have problems with the current hide/show menu because they can't remember how to get it back again (that's why amarok devs chose not to implement it), so how is that any better?

I would prefere a mac-style menubar in a plasma-panel with auto-hide.
This hidden menu is not really nice.

I'm curious as to how this works, but before I voice my confusion I'd like to make a few observations:
1) Although I do use the items in the menu bar, I do not use the all that often - the most commonly used items are already available as easily accessible buttons, and the rest are not used all that often. In fact, the most common thing I ever use the menu bar for is for going to "options" or "settings".
2) I often click on the name or title part of the top window border when moving the window, surely if that became a button it would defeat the purpose - and what if the title was abnormally long?
3) I agree with the concerns that RGB and Kver have voiced.

Now for the confusion: menus were built and designed to be exactly what they are: menus. A menu is not the "start menu", no matter how similar the name. How exactly would you layout the dropdown (I presume) if we used this idea? Would it be a vertical dropdown menu which has a lot of submenus which could make the user lost? Would it be like the start menu, which is designed for a completely different purpose which would actually overwhelm the user instead of helping them? Would it simply cause the horizontal menu to reappear, causing the window to resize, or would it overlay instead? Etc etc - the issue here is not "let's reduce the menu into a titlebar button, it's "if we were to do that, would the new layout benefit users more?" - and by benefit, I'm not talking about clicks

Moult, it seems we entered an agreement loop
Point 2 is important, I think.

@ Scnd101: The problem is not a "learning curve" (a keyboard shortcut to toggle an option is not harder than a button for the same purpose). I think most users do not know about the Ctrl+M shortcut to toggle the menu bar and only when they start knowing how kde apps works and after exploring the menus they will find that option: in that stage of their "learning curve" they will not have problems.
Following the comments by Moult and Kver the ratio cost/benefits of implementing this "button" must be considered.
rekonq implement a "start menu like" button for the options you normally find in a menu bar, but a web browser do not need lots of option: same implementation on showphoto, for example, will be really scaring...

I think, that we need button to activate(display, hide) app-related button/widget on title bar.

Once user click on global menu button, we also give access to KWIN view menu, where user can disables some part of interfaces(like menubar, toolbars, etc.).

@RGB This Ctrl+M shortcut doesn't seem to be part of the window manager, but an application specific thing. It works with Dolphin and Konqueror, but doesn't seem to work with Kate, Kile, Konsole or Amarok.

I don't see why this can't be made an option for the Oxygen theme, or even just allow window decorations to use such a feature, but don't include it in Oxygen.

An idea very similar to this has already been rejected because it requires xembed, which apparently does not work very well.