Peter Penz blogged about removing the Menu from Dolphin. While this is very interesting and nice looking I have a better idea: why not move the menu into the decoration? All what we need is already there. We have the awesome DBus Menu which allows us to send the menu to any other application (in most cases Plasma). So we could use this technology to direct the menu from the window into its decoration. Of course the menu should not be presented in its full completeness but be compacted into one dropdown menu – just like in the Netbook Shell.
So before you all start removing the Menu bar from your apps lets tackle it in a better way. If anyone is interested in working on it, please contact me 🙂
=-=-=-=-=
Powered by Blogilo
Theses mockups are looking so great! but I agree with Milan it should be optional (The liberty of choice is the most powerful strength of KDE SC and Free Software in general)
In the end, that would be really cool if:
-we could choose between these places for the menu:
-in the standard location
-in the window decoration (as on the mockups)
-in the taskbar (à la Mac OS)
-hidden
-being able to choose them at a per application level or at a global level
-to specify the communication protocol with FreeDesktop.org and GNOME for inter-desktop compatibility. (Even if GNOME doesn’t want to implement it the near future)
PaulG sagt:
Theses mockups are looking so great! but I agree with Milan it should be optional (The liberty of choice is the most powerful strength of KDE SC and Free Software in general)
Why not let this setting as keyboard shortcut? Ctrl+M could toggle menu in the decoration or usual place? It will leave everyone happy, bur reduces clutter in the configs 🙂
I would welcome that menu thing, too! :->
+1
BTW, maybe an option to automatically change new windows of an app with the same size as its old windows to KWin tabs?
that option is already available since I think the introduction of KWin tabs.
Beautiful!
I have two sentences that completely represent my reactions:
I want this.
Tell me what I must do to help that come true.
Wow! Stunning! Innovative! Please! 😀
Beautiful idea. I thought something like that one year ago, someone think like me 😀
I like the idea of a Menu Button instead of a Menu Bar. The thing is that I don’t use the default theme/setting e.g. I have the Close/Min/max Buttons on the left side. So i would prefer it to place the Menu Button in the toolbar.
Here’s a screenshot of my current.
http://img854.imageshack.us/i/dolphinnow.png/
Notice the colored title bar to show you which window has the focus, the really centered window title, removed scrollbar buttons and no window borders, but instead a resize triangle in the lower right corner.
Here are 2 screenshots of what I have in mind.
http://img269.imageshack.us/i/dolphinnew.png/
http://img135.imageshack.us/i/dolphinnew2.png/
Notice the Menu Button and also several cleanups like hidden close buttons, centered titles on infoboxes, matching close button for filter/find to tab close, close buttons should fade in on mouse over, mini scollbars with growing slider on mouse over.
So what so you think about it?
I like Unity’s way a little better. It works with GTK, Qt, and XUL apps and even with LibreOffice. If some apps don’t work (Java Swing?) the menubar will be available in the original position. That may be inconsistent, but it’s more inconsistent to have menu buttons in some apps and menu bars in other apps than having the menu bar in the panel in some apps and in the window in other apps. But if that’s optional and workung with FreeDesktop.org standards, I see no problem. Would be great to have an infrastructure to show the menu in the window, in the panel, as a button etc. as you want.
You know the technology we would be used has been implemented by Canonical for Unity. I doubt there will be problems 😉
Oh no… Not that stupid Firefox button to window decoration! Many people wants to keep window decoration clear and simple or on own order (like Mac OS or so on).
And menubar should be hided by Ctrl+M like a shortcut and/or toolbar button (there is already a icon for it when placed to menubar!).
Just add Ctrl+M functionality to kdelibs so _every_ kde application offers it and then add to system settings a global config to enable the menu hiding function and shortcut (by default disabled) so there is no problems by accident.
Wouldn’t client-side decorations be a more general solution? Applications can still have a consistent same look and feel if they use a common library for drawing the decorations.
Gnome has a page discussing this, and even mentions tabs in the title bar: http://live.gnome.org/GTK+/ClientSideDecorations
No CSD is no solution for anything. Please see my various blog posts on why CSD is very, very, very bad. Btw even GNOME stopped thinking that CSD is good by now.
great idea, the hiding of the menubar would allow for making the window translucent as the menubar used to disrupt the applicability of this effect a great deal.
Just a thought, wouldn’t it be more consistent (from a user’s POV) that the menu button be multifunction? I mean, both the app-specific menu items (file, edit etc), the kwin window mgmt items (always on top etc) and application ‘servers’ menu items (window volume -> pulseaudio/oss4/kmix) be cleverly merged into this button! The user wont have to hunt for the kwin window adjacent this btn (would be redundant) as well as putting other functions which conceptually belong associatedvwith a window/app but are not WM related to be integrated (it is the app window, according to the user, that plays my music, not some system tray icon so I should be able to set its volume on the app!!). With dbusmenu, this should be possible as when kwin (the decoration) is composing/building the menu items for the menu, it has knowledge of the kwin items, the app items (through dbusmenu) as well as the application “server’s” menu items (also dbusmenu). Wouldn’t it be nice if the user could stop the printouts of that window (ie if cups advertised its menus through dbusmenu). I see this as a revolutionary feature for KDE
so at the end of the day, who’s gonna do it? what’s the plan? 🙂
I’d be willing to help, but have little coding experience
If this is implemented, please keep in mind:
– Use Canonical work
– Try to put Canonical patch upstream for Qt
– Try to put Canonical patch upstream for Gtk
Please do not:
– Make something working only with KDE apps 😉
You can use kwin in ANY desktop environment so this wouldn’t be KDE only party as long as you use kwin 😉
With all these new 16:9 screens reducing the amount of horizontal lines and the height of the screens itself, it would be useful to organise the “technical stuff” like menus in a more vertical way.
I am alredy doing this with the panel, it used to be visible all the time at the bottom of the screen. With these new screen dimensions it makes much more sense to put them at the side, thus freeing horizontal space for the actual workspace.
Being able to do the same within applications would also increase the amount of horizontal screenspace.
Sure takes some getting used to, but it’s just adapting to a new environment.
Nice idea, but while we’re at it: Window buttons to the left by default… (And this Menu Button to the right)
just because Canonical copys Mac there is no reason to copy that, too. IMHO moving the buttons to the wrong side is the most stupid thing you can do, because most users have (for example at work) to use Windows where they are on the right. There is no need for change for the sake of change.
The same people seems to cope with their new Macs really good. 😉
The most simply logical argument for me is: The mouse pointer points to the left, thus the most basic buttons in an object should be on the left side.
And both Canonical as well as Apple did their research in that matter in terms of usability, I don’t want this called a stupid decision. For example when you overlap several editor windows in a natural way, the buttons on the left are still reachable while the right side of the windows is covered by the next window above.
But I have to admit that this discussion usually will lead to nothing.
“The mouse pointer points to the left, thus the most basic buttons in an object should be on the left side.”
right… but then follows the wrong conclusion (sry.. just my opinion)
on the left side of my windowdecoration is the “keep above” button.. ( i often wonder why this great feature is not visible by default…)
while working i am using this button quite often.. BUT while working i DO NOT USE the “close” button or the “minimize” button because this just interferes with the definition of “working” ^^
i believe that those buttons on the right are NOT important and therefore they have to be hidden from the users attention so he (or she) would not hit those buttons (especially the close button) accidentally.. the best place for that is therefore on the upper right side (maybe the lower right would be even better)
btw @martin: please add the “keep above” button to the upper left side..
everyone who learns about this button loves it
(for example my students.. the love and use it from the very second they see it the first time)
(or at least do not hide it under “advanced” – even “shade” is more visible – which btw. can’t be turned easily of because after activating it the appearance of the context menu causes losing focus of the window so it gets shaded and at the same time a window gets shaded its context menu closes – no chance to move the cursor over a contextmenu that is closing right after opening it – i just found out right now.. BUG ? should i file a report? (if you are fast enough moving your mouse over the context menu it sometimes stays visible )
thx anyway!
How does it work with windows groups?
Maybe something like this would work:
Based on the mockup from your blog post, display a fancy vertical overlay on the left side of the application when pushing the button in the window decorations or Alt+F1 (for example).
Put an input box at the top of the overlay that gets the focus and that can be used to find actions (like krunner with Alt+F2 but application specific). Under that, add some common tasks.
At the bottom we could display a reduced (nested) menu for the rarely used functions.
Might work — but in my opinion it’s time we start thinking beyond the “every application has one rectangular window to show its stuff in” train of thought.
For a while I’ve been using two panels: a auto-hide panel at the bottom of my screen showing all the usual stuff, and a mini always-on-top panel at the top containing just a clock, battery indicator and CPU indicator and positioned such that it usually only hides boring parts of the decoration and menu bars.
We could do better though. Apps like kmail and kdevelop have several panels of controls, etc. — do these all have to be stuck in one rectangle, non-overlapping with the rest of the contents of the screen (panels, chat clients, terminals, and what-have-you)? Using a bunch of rectangular regions probably makes the most sense, but obviously GIMP’s hand-managed windows leave a lot to be desired, so probably the window manager would have to do a bit more of the work.
all there already. You can tear off menubars, toolbars, dock widgets and the window manager handles everything just fine. But most users seem to not like a completly cluttered screen with hundreds of windows.
No, I don’t either, and this probably has something to do with why window-manager options to tile or cascade windows went out of fashion a decade or so ago. But is automatic management really impossible, given hints to keep these controls the right shape and associated with the right window?
I think this is a great idea. As of now I am using the “window menubar” widget in a micro, autohiding panel at the top of the screen. This way the menu is always hidden but hovering the pointer near the hidden panel makes it pop out.
This new idea is however much better an much more practical.
Has anyone asked Hugo or anyone from the Oxygen team what do they think about it? This function will have to be supported by the window decorators, so I just thought that it would make sense to have the big guys involved from the beginning.
Of course they are involved.
Wow, that’s exciting to know!
Another thought: “window menubar” offers the option to have either just a menu button (as in the mockup) or a traditional full menu. I think some people might find that option useful, especially because modern styles allow to drag the window from any empty area. This would allow people to save 1 click, which, since many actions on the menubar involve 2 or three clicks, is quite a good thing.
In any case a full menu would come at the cost of not being able to display the entire window title, but only the app name or something like that. That’s why I think it’s not for everyone and if implemented, it should be an option.
Also, in the mockup the menu button displays the app name. This could be awkward in case of long app names and/or long window titles, so if the button said only “menu” or just displayed the app icon there would be some space saved on the title bar. Again, letting the end user choose what they like best with an option (in oxygen-settings maybe) would make everyone happy.
http://kde-look.org/content/show.php/Oxygen-appmenu?content=141254
Working implementation in an oxygen kwin style…
Lionel Chauvin is working on kwin implementation (but should be long to get this in KDE)
Man that was quick! This is very good news….