Menu Button inside Window Decorations

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

125 Replies to “Menu Button inside Window Decorations”

  1. 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…

  2. 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 🙂

    1. 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.

  3. 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).

    1. Would this be possible with Kwin?

      No and it does not really save space. And in KWin we have window tabs in the decoration.

      1. 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.

      2. 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: ). 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.

        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).

        1. Awesome mockup.
          I generally dislike the chrome-style UI, but your mockup makes it look awesome.

        2. “…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!

      3. Here is another example of how would this integrate with the system:

        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).

        1. @Martin, you should upload the file again with a different name. I kept the ppenz’s screenshot name.

    1. 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) 😀

    2. 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! 🙂

  4. 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!

    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.:)

  5. 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.

  6. 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 ?

      1. 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? 🙂

  7. 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.


    1. “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.

  8. 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. 😉

  9. 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.

  10. 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…

  11. Would it be possible to implement that as a kwin plugin to easily enable/disable that behaviour?

  12. 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 ( Another problem with both approaches (your and Peter Penz’s) is that the menu (and its items) are not accessible anymore using the keyboard.

    1. 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

  13. 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.

  14. 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.

  15. Very cool 🙂 I’ve just send you an e-mail to discuss the details how we can integrate this into Dolphin.

  16. 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…

      1. 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. 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 😀

  17. 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.

  18. 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”.


  19. Great idea. So much cleaner than the Windows implementation of dropping the menu completely until you hit the magic alt key.

    1. gtk apps would support it ootb thanks to the work of canonical. i don’t think there is more to collaborate on it.

  20. 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.

  21. 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.

  22. 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.

    1. as you might realise this would be an addition to just and only kwin. so not a problem for you

  23. Umm, would that be too similar to Microsoft’s ribbion? As in a potential copyright issue? Forgive my ignorance on the subject.

    1. copyright cannot be an issue and I don’t care about patents as they are forbidden for software in germany

  24. 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

  25. 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.

  26. seems like something that could drastically improve kde’s “elegance” with relatively little work

  27. 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.

  28. 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. 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!

      1. 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?

        1. and it’s related, it’s part of kde isn’t it?

          No it’s completely unrelated, it’s not KWin. Anything not Menu in KWin decorations is unrelated here.

          i wanted to show that there are issues not repaired since… forerver

          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

          interested in adding another eye-candy instead of give us users basic funcionality

          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?

          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?

          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.

          1. 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

  29. This reminds me at my idea at the kde-forum
    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?

    1. “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.

      1. 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.

      2. 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?

        1. 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.

        2. “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”. 🙂

  30. 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

Comments are closed.