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
I’d love to see that in KDE/GNOME. I wonder how hard would that be to implement this, my coding skills are really weak but if it would depend on me i’d try to do this. I was thinking the same when i read his post. One obstacle would be when someone hides the border to have more working space. Though putting the menu there would practically do the same without removing it…
Could i have some pointers on what should i research to try to get it working? I am using gentoo…
Yes, oh yes 🙂
This is something I was going to propose to you when I saw the post you referred to.
Big thumbs up from me and a pint of lager for anyone willing to do it 🙂
There is already a kwin effect that does this. See here: http://kde-apps.org/content/show.php/Titlebar+menu?content=138804
That is a hack and not what I want to have.
Agreed. It is a hack. 🙂
Forgot to mention that I’m the author of that effect. Ideally it should be done in kwin itself so that it can be drawn for non composited windows. I’d be interested in doing that.
This feature would be a good looking one, but access to the menu requires one click and some mouse movement more. So for quicker access the normal menu is the better choice. IMHO it would be important to give the user the choice if he prefers the better access or the better looking menu (or maybe both if he wants to toggle the menu bar off temporarily).
Oh yeah, something like the Firefox-Button on Windows for all KDE apps would be neat!
http://static.arstechnica.com/ff4review2/ff4windows.png
http://static.arstechnica.com/ff4review2/ff4windowsmenu.png
I was really impressed, when I saw this the first time.
Also, when Firefox maximized, the tabs are in the titlebar, which saves space, too!
Would this be possible with Kwin?
No and it does not really save space. And in KWin we have window tabs in the decoration.
I disagree it saves space.
KWin tabs should act like chrome tabs: When the window is not maximized: title and tabs are displayed. When the window if maximized: tabs are only displayed.
It would allows drag n drop between window groups when not maximized.
It would make sense with kwin tabs too… Take a look at this 5-minute mockup based on Lionel’s mockup from below: http://img52.imageshack.us/i/dolphinmockup.jpg/
The most important things I see lacking in Kwin from KDE 4.5 are an API to allow windows to open in a specific existing group (make a new tab in the decoration), and that the windows from a specific group are not grouped in the taskbar (in a similar fashion to this: http://downloadsquad.switched.com/2009/10/14/firefox-3-7-adds-per-tab-thumbnails-like-ie8-on-windows-7/ ). I also think that if these 2 problems are fixed, most apps in KDE could use the decoration tabs instead of relying on the currently used tabs, inside the application itself.
Here is a rough mockup of my idea, based on Firefox’ Windows Button and Lionel’s mockup.
http://jp-arvela.co.cc/files/dolphin-mockup.png
The important thing to notice here is the natural mix between the application tabs and the menu button. These complete each other, and all apps in KDE which rely on tabs to show documents would ideally use this system (dolphin, rekonq, kate, kword… just to name a few).
Awesome mockup.
I generally dislike the chrome-style UI, but your mockup makes it look awesome.
“…and that the windows from a specific group are not grouped in the taskbar…”
I never filed a wish for this, but I wish for it a lot: I group stuff that is related to the same sub-task, but when looking at the taskbar it’s hard to find the apps easily — for instance, which konsole belongs to which subtask.
The mockups also look very nice!
Here is another example of how would this integrate with the system:
http://jp-arvela.co.cc/files/firefox-mockup.png
In this case, Firefox (which has the perfect interface for this) is completely integrated on KDE, by including tabs on the decoration by default (ctrl+clicking or middle clicking links would open them in new windows inside this window group) and having the native menu (I just copied it from Windows screenshots, as it looks good already). The most important part would be that a Firefox window with multiple tabs would appear as a single entry in the taskbar, which could be expanded to show the existing windows inside that group.
It is also important to have in mind that allowing windows from other apps to be included in the tab bar should be possible, and that the application menu would simply change to the menu of that app. It is also essential to have a good system to handle tab overflow, and a good API that allows apps to open new windows in a group and to identify the windows from the same app belonging in a group (thus, for example, allowing Firefox’ panorama to work easily).
A mockup for fun:
http://wstaw.org/m/2011/03/28/dolphin-default-4-6.png
very nice, may I include it into the post?
yes 😀
@Martin, you should upload the file again with a different name. I kept the ppenz’s screenshot name.
Yay! This is exactly the thing I thought when I read this post. Hope that feature… And the option in Oxygen to put the titlebar in another place (not the top, like in bespin) 😀
Sweet, I like it! It’s simple and elegant. It has also the potential to put order in the title-bar (currently, a newbie would have to guess hard which one is the application name).
Can’t wait to see it implemented. Keep up the good work, guys: KDE is getting more awesome at every release! 🙂
Crosses fingers so that is implemented!!
I have also posted some time ago this idea in the brainstorm forum, including some (crappy :-p) mockups. Of course Nuno Pinheiro would have better appearance ideas!
http://forum.kde.org/brainstorm.php#idea91172_page1
http://ompldr.org/vNXpjdQ
http://ompldr.org/vNXpjdA
Maybe also a KCM for Menubar appearance, i.e. Traditional, Global, KWin Menu could also be considered.
Just dropping some input to the discussion. Thanks for your all for your efforts.:)
Lionel Chauvin beat me to it and also his mockup has a nice detail, in that the Application Name is not duplicated in the Title.
If i understand Qt right it wouldn’t make application use more memory as it would point to the same menu object right? The issue here is for the application to “broadcast” the address/menu with dbus ?
But what of folks who do not use a window decorator?
They will have the normal decorations
I’m not getting it perhaps. I meant, what if they do not have window decorators running at all, not KWin, nor anything else? Would menus still be available? Is the dbusmenu-qt way also setup to cover that? 🙂
Woah, this is great feature. Is it kind of late for adding it as a task for GSoC?
Not enough for a GSoC
+1 from me, Go for it!
I like the idea of replacing the menu bar by a menu button in kwin in general.
However, i see some obstacles that need to be overcome first. All the apps i know which replaced the traditional menu by a single button (firefox, rekonq, chrome…) not only put the menu into abutton, they also changed the menu structure and put the more important items on top to spare the user unnecessary clicks and mouse movements. Furthermore they removed many traditional menu items. Otherwise the button menu would have had too many levels and items and been to complex.
What we need is some way to allow the applications to expose an alternative menu for the button. If they do this the button should be shown. If not we should fall back to the traditional or global menu.
crabman
“What we need is some way to allow the applications to expose an alternative menu for the button. If they do this the button should be shown. If not we should fall back to the traditional or global menu.”
In my opinion it should always be possible to display such button even with a full menu bar packed into a single menu.
Moreover it should never be displayed by default unless the developper provides an alternative menu. Xmlgui should be improved for that because currently the alternative menu of rekonq is hard coded.
I’m sure you have thought already but I can’t help myself from pointing out, when maximised or left-snapped there should be no border/padding between the button and the left-hand screen-edge. 😉
Just gorgeous, that idea. And +1 for the idea of implementing a nice firefox-like menu in the apps.
Lets hurry up guys! 4.7 timeframe is running. At least one working application in KDE SC as a prototype would be nice in 4.7, so other cna implement it also.
Dolphin and Gwenview are perfect for that.
I hope this will not become a default option! I know it is popular these days to pseudo-save few pixels of space, but can you see the blank space on the right side of the window in the mockup? Why putting menu button somewhere where it does not belong when you have dedicated space for it?
Maybe I’m just paranoid, but I worry Ubuntu people are coming to screw up KDE…
Would it be possible to implement that as a kwin plugin to easily enable/disable that behaviour?
will this be automatically implied as the decoration has to support it – which is a plugin.
This idea and the (very nice) screenshot of Lionel Chauvin is a good replacement for the “global menu” (the menu similar to the menu in Mac OS). Personally I hate the “global menu” because in my opinion anything that is controlling the current window should visually be inside the window. Therefore this idea of having the menu in the decoration is much better: now the menu of the window is still inside the window. From a usability point of view I think however that such a menu would be harder to use because it adds another level of submenus (what is in the old situation the menubar, is now a submenu of the menu button in the decoration) and I find it difficult to browse submenus (because I am unable to move the mouse precisely, so often the mouse pointer moves outside the submenu which then disappears and then I have to move the mouse again to the menuitem which triggers the submenu and then another imprecise movement can make the submenu hide again, …; this is also the reason why I hate the toolbar extender mechanism in Qt 4). While I support implementing this idea (as an option of course), I think that Peter Penz’s idea is also good; see damipereira’s comment (http://ppenz.blogspot.com/2011/03/menu-bars.html?showComment=1301335891404#c7273751351823034382). Another problem with both approaches (your and Peter Penz’s) is that the menu (and its items) are not accessible anymore using the keyboard.
Not at all, inside KWin we could have a shortcut to open the menu of the currently active window
So this could be applied to all the gtk and qt applications? If so, it makes this probably the best way to proceed. The menu-button in toolbar is definetly better than the usual menu but it wouldn’t be consistent with the rest of the desktop. That problem away, this could really differentiate KDE from the rest of the mass, in a good way. So I say, go for it.
Any application supporting dbusmenu would work and the menu would be native.
that is something I’ve been thinking about for awhile. I would like to see it in both gnome and kde. instead of using a global menu like Unity does this should be the standard because it also solves the unnecesary and badly categorized menu problem with a one compact menu.
That’s a good idea, looks modern and clean.
There’s one more thing i would like to be done in the gui. The left menu looks like being jammed into the toolbar. I wish it would be move down a little, like in this pic :
http://www.flickr.com/photos/46811114@N07/5569318542/
Very cool 🙂 I’ve just send you an e-mail to discuss the details how we can integrate this into Dolphin.
The main problem with this initiative would be that it is not quite cross toolkit compatible. Java apps (which aren’t really “kde aware” to begin with) would really feel out of place, and other toolkits like WxWidget or others would have the same problems. Thus a lot of useful apps (inskape &all) that might feel like second rate citizens…
well they can also integrate dbusmenu.
Which would require the addition of DBUS in such technologies, and that won’t be an easy task.
Take java as an example, we would have to wait for the initial spec to be written and validated in freedesktop, then create a bug report in the oracle database. And it would be treated if an only if the feature was implemented in all the major desktop, especially in Gnome. The inclusion of such feature (and depending on DBUS too) would be way more difficult in java that it would in Gnome or any of the DE projects given its corporate and not that much desktop oriented nature…
1. nobody uses Java apps :d
2. we lead, they follow, it has always been so. Their problem 😉
3. it’s a chicken and egg situation anyway, and I’m sure we’ll just push forward instead of waiting for them to catch up with the world, thank you 😀
This is very nice, I like both ideas, the Chrome way and the way in the screenshot.
I see a problem with adding it into the window decorator, if it is hidden (space reasons), then there is no menu left. But I think there could be and option to automatically add the menu to the toolbar if the win-deco is hidden. But if you add the possibility to have the menu in the toolbar or in the win-deco, or the traditional way, everybody will be happy.
There’s something wrong in this mockup, i think.
From a button menu, like this, I can open a cascade of submenus for each other function that I would select, like the Menu Button in the globalmenu plasmoid.
It’s awful.
This means that, also, the entries about dolphin’s menus bar (and other KDE apps) should be rationalized in a new compact way.
If we must keep menus, in Kwin, in a top panel or where you like them, I prefer all classical entries rather than another “Firefox button”.
Ciao
Great idea. So much cleaner than the Windows implementation of dropping the menu completely until you hit the magic alt key.
Would you be collaborating with GNOME on this?
gtk apps would support it ootb thanks to the work of canonical. i don’t think there is more to collaborate on it.
Nice, fits perfect to my Opera 🙂
+1
This is amazing, and that was what I dreamed for KDE. This gives 2 new options.
1. Scrap the menu entirely and turn the blue “Dolphin” button into a mode selector. Dolphin already has multiple modes (you know all of them as kioslaves) When I enter nepomuksearch:/ in the address bar, I get a search. When I write timeline:/, I get a different mode. These modes are WELL hidden. Why don’t replace the menu with a “Mode selector”? And better yet, why don’t you do different interfaces for those modes? (a graphical timeline for timeline:/, a contextual display for nepomuksearch:/, and so on)?
2. Move the breadcrumb to the titlebar, or invert the position of the button bar and breadcrumb. That movement seems logical to me.
while i like this idea, there are those of us that have “removed” the titlebar when the windows are maximized (BorderlessMaximizedWindows=true) so i would like to have a menu button available to be placed on the toolbar.
This is a terrible idea because sadly not everyone uses a window manager with decorations that would be able to support this… pretty much everyone with a tiling window manager would be fucked over unless this was made optional.
as you might realise this would be an addition to just and only kwin. so not a problem for you
Umm, would that be too similar to Microsoft’s ribbion? As in a potential copyright issue? Forgive my ignorance on the subject.
copyright cannot be an issue and I don’t care about patents as they are forbidden for software in germany
Microsoft has no patent or copyright over Ribbon. It has prior art.
Yes, plz.
I am very supportive of this for many, if not most KDE apps. I also agree that thinking about this together is a good idea, rather than having per-application implementation (Rekonq does it one way.. Dolphing another way..) I like the Menu and Tab button mockup in comment #28
I’m sorry I’m not good at English and hope you can understand my comment.
There will be more space but hardly lose convinience with this design. I really like this apperance and hope it can be a standard part of KDE. It will be better if the menu can pop out just by mouse hovering.
It looks very clean and elegant and I’m personally don’t need the menu bar very often.
Like it!
seems like something that could drastically improve kde’s “elegance” with relatively little work
Hallo,
I read with great exitement that KDE thinks about removing the menu bar. In every app which allows this, I allready hide the menubar. I almost never need it.
I have the idea of letting the menubar collaps in every app and indicate the collapsed bar using a tiny icon. But moving it into the window decoration seems to be a great idea. Btw, tabs also could be moved there.
Please think further in this menu free direction. Doing it in a clever way (I have no doubt about this) I think this is a good step forward in usability and elegance.
This makes apps so much cleaner, awesome!
If you need a helping hand and think I could be of any help implementing this, please let me know.
The ideal solution would be one that doesn’t simply add a menu “button in window bar option” but allows flexability in the interaction between the window manager and the application.
There is a similar issue with the menu bar in a panel (i.e. mac OS style), but there a plasma component also needs to interact with the application.
+1 for this amazing idea
it looks nice and would be great to have this in kde but switchable between old menu and this new style – so that way everybody would be happy…. BUT WHAT ABOUT FIXING SOME ANNOYING BUGS like this black corners
http://bugsfiles.kde.org/attachment.cgi?id=53975
(since kde 4.0beta for chirst’s sake)
How strong do you think are your chances that I will fix your pet bug if you come to my blog and yell at me in completly unrelated posts? I seriously don’t understand the attitude of some users. If you want me to fix it for you, please contact me to arrange payment. It won’t be cheap. But as long as I donor my spare time users won’t yell at me or demand bug fixes and this blog is not a bugtracker!
sorry, i didn’t meant to offend you, i post it here (and it’s related, it’s part of kde isn’t it?) because you are big figure in kde world and i wanted to show that there are issues not repaired since… forerver and you guys in kde (i really appreciate your work) are sometimes more interested in adding another eye-candy instead of give us users basic funcionality
i’m sending bug reports where they should be but many of them stays not handled for years so what is the point of bug tracking if noone is going to fix them?
No it’s completely unrelated, it’s not KWin. Anything not Menu in KWin decorations is unrelated here.
You know: I couldn’t care less. We have thousands of bugs and three years is not forever. In KWin we have bugs which are more than three times older than that! And your bug is easily to solve: use compositing
And your bug is what? Bad eye-candy with compositing disabled! How can you justify that anyone of us fixes this bug, if is about eye-candy?
So you think Spamming the Web is a better solution? Have you had a look on how many bugs are opened and fixed each week? We don’t have the manpower to each bug. Wish we could.
I thought for quite some time to add a disclaimer to my blog posts to delete any bug comment.
sorry if I upset you I didn’t meant to and doesn’t understand why you are so pissed about that post I wish you best of luck, it’s just hard to recommend kde to someone when there are glitches all over the place and composition is not answer to everything, you especially should know what is the situation with graphic stack/drivers on linux
sorry for being douche bag and hope you’ll work on kwin to bring us user better experience as always you did, Im just picky about details and wish kde to be free of papercuts
I LOVE IT! 🙂
It looks really nice and furthermore gives more vertical space on small screens!
+1 for this
I’d also love to see this in 4.6.x or 4.7
This reminds me at my idea at the kde-forum http://forum.kde.org/brainstorm.php#idea84726_page1
Several ideas of this type got tagged “Wont fix”.
It seems like some kde-‘managers’ don’t like this idea.
I really like it but there should be an option to switch between the normal menubar and the menubutton.
There is also an intersection of the tabs inside an application and on top.
In Chauvins mockup, two firefox’ windows are inside the titlebar. Atm, tabs on top are only for windows, not for tabs of the application. If tabs on top are activated in firefox, we have 2 rows of tabs one above the other, which looks really ugly.
In my opinion, this should be merged (optional only ONE rows of tabs)
Is there already someone who’d program the menubutton?
“It seems like some kde-’managers’ don’t like this idea.”
Is it really necessary to flame? Even if it were true, it has nothing to do with why the idea was rejected.
Ideas are marked as “Won’t fix” based on information we get from the developers. When rejecting an idea we always try to explain why, like in this case: “An idea very similar to this has already been rejected because it requires xembed, which apparently does not work very well”. Such a solution was considered hackish and wouldn’t be accepted by the KWin developers (as far as I know) and I don’t think DBusMenu existed back then.
Remember, the forums people are also volunteers who contribute on their spare time. If you’re unhappy about a decision, don’t hesitate to write a comment or to contact us.
Just as a note: this idea I blogged about actually comes from the Brainstorm Forum and was filed as a wishlist item in our bugtracker. It is not my idea! So yeah we listen to users if ideas are good and yeah with xembed it would not have been accepted.
I don’t want to flame. The mark as “Won’t fix” just looks like “we don’t want this idea implemented in kde” because it is no impossible task , like we see with dbusmenu, to implement the basis techniques. And if you _want_ a feature it is possible to try to make e.g. xembed better working.
Because of that I was just wondered about the general opinion of the kde developer team.
And that’s my next question; Would it be implemented if we had a working solution?
developers do not often respond to such threads. It is likely that it was not even looked at, just a response like “we won’t use xembed” without actually thinking about it. Would probably be my response, too, when I am busy or have not the time to response properly. Remember we are all jus humans and most user ideas are sorry to say so completely useless.
“I don’t want to flame. […] Because of that I was just wondered about the general opinion of the kde developer team.”
To me your first post seemed to indicate that the people managing Brainstorm close ideas they don’t like, which simply isn’t true. These people put a lot of time and effort into Brainstorm to make it easier for developers to find the popular ideas without the noise (duplicates etc.). Thus, if an idea has been rejected by the developers before, it will be marked as “Won’t Fix”. As an example “Remove the desktop tool box (cashew)” would be rejected since the Plasma developers have stated several times that it won’t be removed.
At that time it was not possible to implement this idea in a satisfactory way. If you had posted a comment or sent a PM to the Idea mods about the new solution (DBusMenu), I’m sure the original idea would be reopened – although hopefully it would be marked as “In Progress”. 🙂
+1 also; very nice looking; should have it in kde 4.7 at least. please 🙂
As long as it is optional I like the idea, but previous post I read about removal of menu is ridiculous. Those menus in all applications are not there by accident, apps have options, tools, actions etc. and many users wants to, well, use applications, not starring and watching how beautiful (and less cluttered?) they are.
I recently switched from Gnome to KDE, and also from planet Gnome to planet KDE. I was very happy when I saw that I have an option to choose which WM I want to use. That is what I like about KDE, respect for users and not force them to use something they don’t want, give user an options!
I guess if I am using openbox this doesn’t affect me at all, right? Thanks
I Love it! I want it for all KDE Apps.