is outdated. I moved my blog over to See you there.

Getting menubars out of application windows…

Today at the Maverick Ubuntu Developer Summit (UDS) I gave a quick demonstration of a project I have been working on for the next Kubuntu version. It is a DBusMenu-based implementation of a global application menu. This is a feature which was in KDE 3.x but has not yet been ported to 4.x.

Here is a screenshot of Dolphin running with its menu embedded in a Plasma panel.

The nice thing about this implementation is that it takes advantage of DBusMenu: GTK+-based applications running on a KDE desktop will be able to get their menubars displayed in the Plasma panel. Same thing for KDE applications running on the GNOME desktop. My colleagues are busy finishing the GTK+ implementation right now.

The Plasma Menubar widget also features a “Button form factor”. Enabling it turns the menubar into a “Menu” button, saving a lot of space in the panel. This makes it possible to pack both the Menubar and the Taskbar widgets in the same panel like this:

This is quite handy for Netbooks. I have been using my laptop with this setup recently and I find it nice to work with. The cost of the extra-click to get to the menu items does not bother me for now.

Finally, here is a short screencast of the menubar in action:

ogv version

This is implemented as a patch for Qt. Right now the code is quite experimental, misses a few features and crashes when it feels like it. It should thus be considered a proof-of-concept implementation. If you feel adventurous, you can install the patched Qt version as well as the Menubar widget from my PPA the Unity PPA.

The Menubar widget is hosted on Launchpad. I haven’t uploaded the Qt patch yet but it can be found in the source Qt package in the PPA. I have to warn you it’s quite ugly, though: it currently embeds a hacked-up version of dbusmenu-qt inside Qt itself. Luckily Qt developers joined us at UDS, so we should get this solved in a cleaner way.

Flattr this

127 Comments on “Getting menubars out of application windows…”

  1. mario says:

    absolutely awesome! that has to get merged into KDE! im waiting years for a decent implementation of this menubar.

    • Sunil says:

      Me too!
      Thank you for this, especially for the netbook implementation :)

  2. Keith says:

    Wow nice job. I can’t wait for this :D. But the only question is. My application uses a Tab widget that’s in the menubar just like KDevelop4 IDE does. What will happen when I use this in the global menubar?

    • Aurélien says:

      Not sure how KDevelop4 would behave with this. I need to try it. In the worse case an application can decide to opt-out from the global menubar by using QApplication::setAttribute(Qt::AA_DontUseNativeMenuBar, true)

      • Christian says:

        KDevelop4 is broken this way, but a blacklist or opt-out option could help here.

        • John M. says:

          Why is it “broken”, just because it doesn’t comply with *your* idea of what an application should do with it’s title bar space?

          Other applications like Palapeli also put custom stuff like tabs in their menu bars. Kexi2 has even merged the menu and tool bars in an interesting way. On the non-FOSS front, we have Microsofts innovative ribbon UI.
          As a user, I find all this this very useful and worth pursuing more, so a distribution/desktop environment should try it’s best to play nice with Applications that experiment with such modern and creative approaches, rather than just label these apps as “broken”.

          Nowadays, it’s common practice for applications to have tons of innovative controls and interactive elements in their *toolbars*, but *menu bars* are mostly still boring, text-only and sterile like in the 1990’s. Why criticize applications that try to change this?

          • Aurélien says:

            I think what Christian meant was that the global menubar breaks KDevelop4, not that KDevelop4 is broken.

            • John M. says:

              Oops, you’re right. I totally misinterpreted his comment.
              Sorry for that…

              • eigenraum says:

                Yes, Aurélien is right, I didn’t mean that KDevelop4 is broken but that the global menu bar is breaking it[1]. But your points are right. Application developer should be able to prevent that the menu bar is extracted from the application window.

                [1]: Other applications that have problems with a global menu: dolphin – it shows a “Show menu bar” in the context menu; and the menus in VirtualBox (but only in the window of a running instance in the new version 3.2)

    • Stefan says:

      @keith: If your application uses this pattern, and KDevelop does, too, and Palapeli does, too, it might be the right time to think about a generic solution.

  3. Rp says:

    Nice!! Keep the good work!

  4. Fri13 says:

    I would really hope this would be added for KDE SC 4.5. But if it is not possible then at least to 4.6 release.

    Just looks so awesome!

  5. Livio says:

    Awesome. Wish to see a GTK app integrated too. Willing to show us a video :> ?

  6. Andreas says:

    Fantastic! Please commit to appropriate places so we can get this goodness :)

  7. Alex says:


    Seriously, this is something I have long dreamed of. “Awesome” doesn’t quite do it justice.

  8. atomopawn says:

    Very nice. I’m curious, though — how does this interact with keyboard shortcuts? Is it still be possible to hit “Alt-f s” to save and so forth when using the menubar this way?

  9. ChALkeR says:

    Cool. Hope it will be standart (fdo?) and not so buggy as bespin implementation.

  10. pano says:

    I wonder how this would behave when using apps that do not have a “real” menu bar (e.g. rekonq).

  11. furanku says:

    Great! Thank you very much, I missed that feature since the first days of KDE 4!

  12. Markus says:

    I hope you act wiser than your Canonical colleagues who implement stuff without coordinating with upstream at all. (Please don’t do Windicator shit)

    Btw, I wrote a netbook GUI proposal a while back:

    The discussion is in the plasma-devel archives.
    My proposal was not that well received, I might add in all fairness. But considering that most of the points in my proposal are built on existing Plasmoids a distributor could draw from my proposal, possibly enhance the existing Plasmoids, and ship something like that without tainting KDE’s Plasma with unupstreamable code.

  13. crabman says:

    Very cool!
    What happens if an application has custom widgets inside its menu?
    I mean things like the radiobuttons ins amaroks view menu or e.g a zoom slider, a spinbox, a lineEdit and so on?
    Thinking this even further: what happens when a Qt app has a spinbox in its menu and is run in GNOME? Is it rendered by Qt inside of the gtk+ toolbar?

    • Aurélien says:

      We plan to extend DBusMenu to support more custom widgets, but it won’t be able to support everything one can create in a QMenu. We need to work on a case by case basis with developers of applications which use custom widgets in their menus.

      If you have some applications in mind, please share their names: we are going to do a review of what is shipped in Ubuntu, but the more people we have to look the less likely we might miss one application.

  14. Sean Tilley says:


  15. […] vengo a sapere che oltre a GNOME, Ubuntu Light 10.10 supporterà la Global Menubar anche per KDE! Appmenu di Aurelien Gateau è una implementazione di Global Menubar in D-Bus, dunque pienamente compatibile con GNOME. Avevo […]

  16. FiNeX says:

    I like it… but what about the “show/hide” menu entry on the menus (and the common CTRL+M shortcut) ??????

    • Aurélien says:

      This action makes little sense with a global menubar, so I think it should be disabled/hidden when the global menubar is enabled.

      • FiNeX says:

        Don’t forget about it :-)

      • Thales Oliveira says:

        maybe you can use the Ctrl + M shortcut to switch from a “Panel Menu” to the “Button Menu” like you’ve already have in your post =]

  17. Emmanuel Lepage Vallee says:

    Aurélien, you just made my GSoC much easier ;P. The global menubar was the worst part, now, it is done! I can focus on plugable menu item and editable context menu instead of wasting my time on global code while it is not that important for my project. Just a question like that, how do you handle menu QWidgets and corner widgets? Does KDevelop work fine with your implementation. While doing some test, I fould it to be quite problematic.

    Canonical/You talked about systray menu now being a little more plugin friendly when it come to adding new entry in a menu, does it apply to global menu too? Or is it necessary to apply it in the native menu so applications not using global menu bar can have plugable menus entry?

    About the keyboard shortcut, I think it need to be separated from the menu code, so any applications/plasmoid/gnome shell can query the list of (K)Actions to make some sort of “discover your keyboard shortcut” style plasmoid.

    One last thing, context menu also need to be part of this effort. The current model for context menu does not work well for touch screen or MID/smartphone devices. Having them as a d-bus signal instead of a popup menu would allow the view to draw them with such devices in mind.

    Of course, starting may 24, I will work on that too, expanding your base to handle more of these senario. My proposal is all about contextual actions, macro and improving the whole XMLGui thing (with d-bus), so you saved me a lot of time :)

    • Aurélien says:

      Glad I saved you some work! Can you add a pointer to your GSoC project?

    • mado lamothe says:

      Not that thrilled by it. Then again, I hate every default that comes with KDE and prefer things MY way.

      I was reading about the systray menu now being a little more plugin friendly and was wondering (offtopic) if there has been any work done to it to allow the icons in the systray to be bigger.
      It is by far the biggest complaint I get from older users and those with bad eyesight: they can make everything bigger and easier to see EXCEPT the systray icons which is often then rendered useless.

      I know its OT but it just hit me now and its been something thats been user unfriendly towards older users and those with vision problems.


      • Aurélien says:

        Since the new systray is all rendered by the plasma widget, it should be possible to add support for scaling icons to it. Please file a bug on about this.

  18. Kubuntiac says:

    How about saving more space and looking slicker at the same time by replacing the big, ambiguous button labled menu (menu for what, exactly?) with the icon of the app.

    Clearer that it relates to the current app
    More visual
    Multiligual by definition

    • zayed says:


      What if we but the menu button inside the application itself ?

      • Aurélien says:

        This is an idea I like as well, but it’s a totally different approach. Not much code from DBusMenu or the Qt patch would be useful to implement it.

      • Adam says:

        I don’t see how that would save screen space, because the menu bar would still take up space at the top of the window, even if it’s empty.

        • Aurélien says:

          When the menubar is reduced to a button and embedded in an existing panel, your window can use the vertical space previously used by the menubar.

    • Aurélien says:

      Good point. The “Menu” button is still an experimental feature. I agree it would probably be nicer and more space efficient this way.

  19. Dotan Cohen says:

    Thanks! You might want to look at this feature request on BKO:

    “””Collapse menu bar into icon”””

  20. TZ says:

    I hope it’s style-independent?

  21. Christian says:

    Wow, this is awesome, even on a normal desktop computer :-)

    If it can’t be in KDE 4.5, it would be great to have it (maybe as an option) in Kubuntu.

    For sure there are some bugs at this early stage (e.g. Kontact is missing a lot of menu items like “Folder”). I like the the button form factor a lot, but it should not disappear if there is no supported application in focus – the button should just be disabled – otherwise it’s hard to move the widget and other widgets are moved every time I switch between support and non supported applications.

    Thanks for your great work, looking forward to it!

    • Aurélien says:

      Yes, the whole widget needs some polish. Moving the widget is problematic right now.

  22. zayed says:

    What I like more in this, it is does not required to modify the applications. It is done in Qt for all application for FREE.

  23. Jonathan Verner says:

    Really great!!! You made my day :-) Thank you so much!

  24. thorGT says:

    What I most like about this is that there are no icons in menus…… that’s just so awesome…… please, leave it like this, there must be a reason Apple does it this way.

  25. thorGT says:

    Apologize if I’m commenting off-topic (my previous comment on the subject was apparently removed, or maybe lost), but I’d like to say that this is awesome work and I especially like the absence of icons in the menus, which, in my opinion, is the way to go.

    • Aurélien says:

      (Your comment was not removed, it was just waiting for me to approve it :))

      Thanks for the nice words, but icons will be back. They are not there right now because of a dependency issue which should be already solved.

      • thorGT says:

        Ah, so that’s how it works. It was there “Awaiting moderation” and then disappeared, so I thought it’d been modded :) And as far as the dependency issue, yes, I know, I’m following plasma-devel….. would be nice if there was an option “Show icons in application menus”, similar to what Oxygen has for regular buttons. For Oxygen and buttons, it’s the style that is responsible for that, but your plasma representation could intercept menu icons request and allow to choose whether to show icons or not independent of the widget style used. That would be consistent with Oxygen. And nice for people like me who, well, like Apple ;)

  26. elcuco says:

    I am a little worried about RTL implementations.

    What happens when the language (direction) of the application does not match the direction of the panel? For example, I run a “Hebrew” dekstop, but then an “English” Application?

    You need (somehow) to detect the direction of the application, and then set topMenu->setLayoutDirection(thatOtherApplicationDirection). This should be done EACH time you change application, and when applications change “direction” (you can always change the layoutDirection() of your main window.

    Aurélien, contact me, my email is trivila to guess (add to it) and you also have my GMail.

    • Aurélien says:

      Very good point. I haven’t tested RTL support. I just added this to my list of things to check/implement.

  27. Magnus says:

    How does global menus work when using window focus following the mouse pointer?

    • Aurélien says:

      Probably not very well I am afraid. Except if you use a shortcut to focus the menubar (this is not in yet). There may be other, more appropriate, visualisations for this case though. Since the content of the menubar is exposed on DBus, one could imagine KWin displaying the menubar in its title bar (without Windicators!)

      • Adam says:

        I use this in KDE 3.5 by setting a delay before windows are activated. This way, if the cursor has to move across another window before it reaches the menu bar, I can just move it there quickly, and it arrives before the other window activates. Certainly, I wouldn’t recommend this as a default setting, but it lets me save screen space on my laptop and save clicks by using “focus follows.”

  28. […] [via] […]

  29. […] a Bespin ma le cose cambieranno presto: Aurelin Gateau (sviluppatore di Kubuntu) sta facendo esperimenti con DBusMenu ed ecco cosa è riuscito ad […]

  30. Dirk says:

    Nice work, but to me this is bullshit!

    There is a logical connection between the window and it’s menu. Why the hell would someone (who is not a mac user thinking macs are superior) loose this connection by putting the menu outside the window?

    • Aurélien says:

      Thanks for the nice words :(

      To me the primary advantage of this work is to save space by embedding the menubar in the panel.

      • Dirk says:

        And you need a panel there to display the menu = waste of space. If i want to use the space as best as possible, i use wmii :)

        Oh, and what about the “saved” space? You save – lets say – 20 pixels in the window but you lose 20 pixels on the top or the bottom of the desktop.

        • Vide says:

          You smart, you lose 20 px on the top (the panel) but you gain N*20px where N is the number of apps you are running. Obviously these are not all pixel on the same physical screen but pixel in the, let’s call it so, “applications-virtual-screen”.

          And yes, this is a copycat of OSX but this has been present in KDE 3.x for years

          • Dirk says:

            No, you don’t lose N*20px, you do not “stack“ the application windows (or do you stack them?). If you order your windows in a kind of column, THEN (and only then) you really save pixels, but if you use multiple “layers” (overlapping windows) then you save nothing, but in the end you’re not losing any space.

            • Livio says:

              Don’t want it – don’t use it. And keep silent as many others want it.

              • Dirk says:

                Says who?

                • FrancescoK says:

                  Putting the menu bar on top, predictably and consistently, makes me access the menus quicker than when they are integrated in the window, because it takes almost no precision to aim for the edge of the screen, while it takes quite a bit more effort to correctly hit the menu bar of a single window which may be anywhere. The workaround, obviously, is to work with all the windows always-maximized, as many Windows users do, which to me counters the whole idea of multiple windows.

                  The space-saving to me comes less from vertically stacking windows – something I sometimes actually do – but especially because you would want to put the K-Menu and applet indicators in the same container, not considering autohiding. Yes, like Mac OS, copying be damned.

                  In the end, maybe it’s not something you may want to put as default for KDE, but as an option it’s something quite a number of users would love to have. Me for one.

                  And, regarding the “logical connection”: The logical connection is between the menu and the active program and window, not between the menu and any window of any program. Granted, KDE tends to lump “window” and “program” together most of the time, but just as keyboard shortcuts only work within the active window of the active program. So, to me, the menu, just like keyboard shortcuts, are something only related to the active task at hand, and more suited to a system-wide single implementation at a predictably consistent and easy-to-reach position.

                  Just because it takes a bit of getting used to if you are used to menus on windows doesn’t make it a stupid idea, a broken design or something no-one wants :)

            • FiNeX says:

              Probably the idea behind a single menu bar is to have the desktop like a big MDI application.

        • Aurélien says:

          If I am using the button form factor, one can embed the menu in an existing panel so the menubar space is really saved. This panel can even be setup to autohide if vertical space is running out.

  31. Adam says:

    Thank you for your work on this feature, and for sharing it here. I am very much looking forward to having this feature back in KDE 4.

  32. […] Getting menubars out of application windows… Today at the Maverick Ubuntu Developer Summit (UDS) I gave a quick demonstration of a project I have been working on […] […]

  33. furanku says:

    Is it just me or do you also miss a comment from A. Siego? NIH- and “Master of the Game”- Syndrome here we come! :(

    • Aurélien says:

      You are confused here. Aaron has been a great supporter of dbusmenu, the technology used for the global menu. He strongly backed me up after my not-so-great commit introducing dbusmenu as a kde dependency in trunk.

  34. Andreas says:


    The space needed to render the menu or the menu bar is about the same yes, so if you only have 1 window per desktop you would gain nothing. If one on the other hand have >1 window one have saved (#windows-1)*sizeof(menu)…

    I loved the feature in KDE3, which however had one slight problem: with focus follows mouse, it’s hard to get the pointer to the menubar without chaning context…

  35. […] Getting menubars out of application windows (blog de Aurélien […]

  36. […] Getting menubars out of application windows (blog de Aurélien […]

  37. Stefan Majewsky says:

    Will API be provided to let the app determine whether its menubar has been moved out of the window?

    I’m asking because of my creative abuse of the menubar in Palapeli (a screenshot is at for example). I assume that the current Palapeli would display just “Settings” and “Help” in the global menubar and leave the tabs inside the window, which is clearly suboptimal, so I’d like to implement an optimised layout for the global-menubar case.

    • Aurélien says:

      Yes, you will be able to query whether the global menubar is available with QMenuBar::isNativeMenuBar()

  38. lelamal says:

    Hey, thanks for sharing. I’m sure this is gonna be an awesome feature! I hope to see it implemented in Kubuntu 10.10!

  39. mario says:

    when will the patch land in qt trunk? or is it already?

    • Aurélien says:

      No it’s not in trunk yet. And it won’t reach Qt until Qt 4.8 because 4.7 is in beta.

  40. Yaohan Chen says:

    It would be nice if the menu bar, task bar, system tray and a bunch of other widgets could fit in one panel. I think this solution would work well for me:

    The menu bar and task bar share a segment of the panel; if they are too long to be both displayed fully, the menu bar will take precedence, but at least a little of the task bar will still be shown (with a gradient fade out effect to show it’s truncated), and when and only when the mouse hovers on the partial task bar, the task bar expands, and the menu bar is partially cut off.

    Maybe there should be a general way to combine any two adjacent widgets in a panel this way, letting them share space and both remain functional. Could this be done with a containment?

    • Aurélien says:

      You can already put everything in the same panel, but the menu and task bars compete for space, so there are a lot of resizes. I find that using the menu bar in button mode is a nicer way to operate if the panel contains a task bar.

  41. docidu says:

    Well, this is one of the things i hated most about OSX, but as long as it isnt turned on by default, more options are a good thing….

  42. Merlin says:

    I’ve been waiting for this for SOOOO long!!!

    will we be able to download it from

    I would really like to get my hands on this right now!!!

    • Aurélien says:

      This requires a Qt patch so it can’t be made available on If you run Kubuntu you can give a try to the PPA mentionned in the article. If you are familiar with building software from source, you can apply the patch and build the plasma menubar yourself.

  43. Thales Oliveira says:

    So, when is it gonna be ready to use?
    Have you tested it on KDE 4.4? (I don’t know if there’s a difference)
    I tried this menu last month and I messed up my hole KDE ^^

    • Thales Oliveira says:

      sorry I wanted to say: KDE 4.5

      • Aurélien says:

        You need the appmenu Qt patch for this to work. Kubuntu will ship the patch in their version of Qt 4.7. We plan to get the patch integrated in upstream Qt for 4.8.

        This means to get it to work on your desktop you need either to apply the Qt patch yourself, use Kubuntu Qt 4.7, wait for the patch to be in upstream Qt 4.8. Then you only need to build/install the Plasma menubar widget, which is independant (for now) of the KDE release.

        • Thales Oliveira says:

          So it means that we can already use it? As I said I tried to install it, and it did not work. Is there a way to make a tutorial explaining how to install and configure it for people like me who don’t really know how to do it?

          Thanks anyway,


          • Aurélien says:

            It’s still quite experimental. I would suggest not trying it if you need stability and don’t feel comfortable playing with alpha code. By the time Ubuntu Maverick is out, it should be usable by everybody (otherwise I am going to run into trouble with my manager :) )

            • Thales Oliveira says:

              Okay, I got it, thank you anyway :) I’m so anxious to use it.
              Would you like any help? I’m a web developer/programmer so I think I cannot help with codes, but if you need something like tests or another thing let me know, ok?

              Thank you very much again,


  44. strife says:

    Hope this gets available for desktop kubuntu aswell and not just the notebook version!!!!

    I want!

  45. […] immer oben in der Kontrollleiste sind. Das spart Platz. Im Blog des Enwicklers kann man sich ein Video dazu anschauen (auf “Click To Play” […]

  46. Praveesh K P says:

    Really awesome . It not only is useful in netbooks , but also in desktop computers too . Iam using it in my desktop pc (Kubuntu Maverick RC)and I have to say it is absolutely awesome. If possible, please send the patch to upstream

  47. Merlin says:

    So tell me,

    is the patch still going to get into QT4.8??

    What news do you have about this?


  48. Zephyr says:

    Thanks for your terrific work Aurelien!

    Global Menubar works great yet I have an idea about implementing it as a KWin Decoration Button.
    Please have a look at this link:

    Also when plasma widget appmenu gets upstream into KDE SC and if my proposal is made true, a KCM that has 3 options (1. “old” bahavior – 2. add plasma-panel with appmenu – 3. use kwin button menu) could be useful.

    • Aurélien says:

      Interestingly, one of the Kubuntu devs played a bit with this idea back when we started to work on the appmenu. It requires some work on the way the appmenu plasma applet is implemented for this to be possible, but when it’s done (and it should hopefully be done for next Kubuntu), it should be possible to implement a kwin decoration to show menubars (or a menubutton as you suggested).

  49. Zephyr says:

    I see! That’s great!

    Thank you very much and keep rocking!

  50. drja says:

    So I installed menubar plasma widget on my fully updated Kubuntu Maverick and, well, it really helps getting some screen space without sacrificing usability :)
    One question though: how are things going when it comes to support of sudo/kdesudo Qt apps? At my desk, running, say, Dolphin as root (whichever way) makes it display its menubar the classic way – plasma widget seems to do nothing about that, with just File->Quit available. Well, I guess this is not the intended behaviour… Any options to fix that?
    Thanks for your work anyways :)

    • Aurélien says:

      It is indeed a problem, but we haven’t defined any workaround yet. Not sure what we could do to avoid that.

  51. Antony says:

    This is a great though. I have a tablet pc, so it’s a touch screen device, and right clicking to show the context menus doesn’t exist. This way you can access always the context menu and it’s even better of having to hold pressed the left click because you could miss click, or hold down the click for the wrong amount of time needed etc. The Only thing i found missing is the “open with” option. at least in the kubuntu 10.10 version i’m using i couldn’t find it. Even though you can launch an application from terminal (having it as an option in dolphin) with any program you want, an open with option in the context menu it would be great.
    Is there a way that someone could insert this option or generally menu voices alone or it has to be implemented by you?

  52. […] Getting menus out of application windows […]

  53. Benji says:


    Since, apparently, KDE 4.9 will support QT 4.8 what else (beside qt 4.8, kde 4.9 and the respective Plasmoid) does one need to get this working?

    I’ve read something about appmenu-qt. Does that come with kde or do one has to install it as well?

    • Benji says:

      and that appmenu-qt plugin… will it come with kde or will we have to manually install it?! :(

      • Aurélien says:

        “That appmenu-qt plugin”, as you say, is hosted on Launchpad, not on KDE git repository. I don’t think it is going to change. But that is not relevant. What matters is what your distribution ships. Now that the Qt patch has been included, there is nothing preventing any distribution from shipping appmenu-qt and the plasma-widget-menubar plasmoid.

    • Aurélien says:

      You need appmenu-qt, the Qt plugin which exposes the menubar of Qt applications so that the plasmoid can display them. If you want menubars from GTK applications to be exposed as well, you need appmenu-gtk.

  54. cturkel says:

    I just installed this and wow! Awesome!

    BTW anyway to change the fonts or font styles?

  55. Ken says:

    Hi Aurélien, I\’ve been enjoying using this in KDE already and it seems fantastic.

    The only problem I\’m noticing is that if you have multiple monitors, you really want them to show up where each monitor gets its own menu bar. One natural way to approach this is to have two panels, one on each monitor, and create two applets. Unfortunately the second applet doesn\’t work.

    Any recommendations?

    • Aurélien says:

      The major problem of the applet is it cannot be used twice, indeed. Unfortunately I do not work on this much anymore now that it is no longer part of my job :(


Get every new post delivered to your Inbox.