Getting menubars out of application windows...

written on Monday, May 10, 2010

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.

This post was tagged dbusmenu, kde, menubar and plasma

Comments

mario - Tue May 11 2010, 0:30 - link
absolutely awesome! that has to get merged into KDE! im waiting years for a decent implementation of this menubar.
- Sunil - Tue May 11 2010, 5:51 - link
  Me too!
  Thank you for this, especially for the netbook implementation :)
Keith - Tue May 11 2010, 0:37 - link
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 - Tue May 11 2010, 1:17 - link
  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 - Tue May 11 2010, 12:25 - link
    KDevelop4 is broken this way, but a blacklist or opt-out option could help here.
    - John M. - Thu May 20 2010, 17:30 - link
      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 - Thu May 20 2010, 17:39 - link
        I think what Christian meant was that the global menubar breaks KDevelop4, not that KDevelop4 is broken.
        John M. - Thu May 20 2010, 20:16 - link
        Oops, you're right. I totally misinterpreted his comment.
        Sorry for that...
        eigenraum - Thu May 20 2010, 21:03 - link
        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 - Thu May 20 2010, 19:22 - link
  @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.
Rp - Tue May 11 2010, 0:37 - link
Nice!! Keep the good work!
Fri13 - Tue May 11 2010, 0:40 - link
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!
- Aurélien - Tue May 11 2010, 1:18 - link
  It is too late for KDE SC 4.5, hopefully it should be ready for 4.6.
  - Christian - Tue May 11 2010, 12:26 - link
    It would be nice to have it in Kubuntu 10.10 anyways.
Livio - Tue May 11 2010, 0:52 - link
Awesome. Wish to see a GTK app integrated too. Willing to show us a video :> ?
- Aurélien - Tue May 11 2010, 1:12 - link
  OK, when I get it running on my machine, I'll record a new screencast.
  - Livio - Tue May 11 2010, 1:12 - link
    Thank you in advance :) .
Andreas - Tue May 11 2010, 1:10 - link
Fantastic! Please commit to appropriate places so we can get this goodness :)
Alex - Tue May 11 2010, 1:10 - link
WANTWANTWANTWANTWANT
Seriously, this is something I have long dreamed of. "Awesome" doesn't quite do it justice.
atomopawn - Tue May 11 2010, 1:18 - link
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?
- Aurélien - Tue May 11 2010, 1:20 - link
  It does not work right now, but this is something I want to add to the final version.
  - Chani - Wed May 12 2010, 3:51 - link
    when you do, tell me how you did it...
ChALkeR - Tue May 11 2010, 1:22 - link
Cool. Hope it will be standart (fdo?) and not so buggy as bespin implementation.
pano - Tue May 11 2010, 1:27 - link
I wonder how this would behave when using apps that do not have a "real" menu bar (e.g. rekonq).
- Keith - Tue May 11 2010, 1:46 - link
  probably be just like chromium
- Aurélien - Tue May 11 2010, 1:51 - link
  Rekonq is not affected by this and just shows nothing in the menubar right now.
furanku - Tue May 11 2010, 2:00 - link
Great! Thank you very much, I missed that feature since the first days of KDE 4!
Markus - Tue May 11 2010, 2:02 - link
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: https://kamikazow.wordpress...
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.
- Aurélien - Tue May 11 2010, 10:24 - link
  Thanks for the pointer, I am going to have a look at it.
crabman - Tue May 11 2010, 2:05 - link
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 - Tue May 11 2010, 10:27 - link
  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.
Sean Tilley - Tue May 11 2010, 2:33 - link
FINALLY! I HAVE A REASON TO LIVE STILL!
FiNeX - Tue May 11 2010, 3:10 - link
I like it... but what about the "show/hide" menu entry on the menus (and the common CTRL+M shortcut) ??????
- Aurélien - Tue May 11 2010, 10:28 - link
  This action makes little sense with a global menubar, so I think it should be disabled/hidden when the global menubar is enabled.
  - FiNeX - Thu May 13 2010, 19:58 - link
    Don't forget about it :-)
  - Thales Oliveira - Sun May 23 2010, 19:54 - link
    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 =]
Emmanuel Lepage Vallee - Tue May 11 2010, 3:18 - link
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 - Tue May 11 2010, 10:29 - link
  Glad I saved you some work! Can you add a pointer to your GSoC project?
- mado lamothe - Thu May 13 2010, 8:19 - link
  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.
  Cheers.
  - Aurélien - Thu May 13 2010, 11:10 - link
    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 http://bugs.kde.org about this.
Kubuntiac - Tue May 11 2010, 3:53 - link
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.
Smaller
Clearer that it relates to the current app
More visual
Multiligual by definition
- Aurélien - Tue May 11 2010, 10:31 - link
  Good point. The "Menu" button is still an experimental feature. I agree it would probably be nicer and more space efficient this way.
- zayed - Tue May 11 2010, 11:26 - link
  +1.
  What if we but the menu button inside the application itself ?
  - Aurélien - Tue May 11 2010, 12:28 - link
    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 - Wed May 12 2010, 3:22 - link
    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 - Wed May 12 2010, 11:01 - link
      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.
Dotan Cohen - Tue May 11 2010, 11:40 - link
Thanks! You might want to look at this feature request on BKO:
"""Collapse menu bar into icon"""
https://bugs.kde.org/show_b...
TZ - Tue May 11 2010, 12:11 - link
I hope it's style-independent?
- Aurélien - Tue May 11 2010, 12:27 - link
  It is: it is implemented as a patch for Qt.
Christian - Tue May 11 2010, 12:23 - link
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 - Tue May 11 2010, 12:29 - link
  Yes, the whole widget needs some polish. Moving the widget is problematic right now.
zayed - Tue May 11 2010, 13:25 - link
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.
Jonathan Verner - Tue May 11 2010, 13:52 - link
Really great!!! You made my day :-) Thank you so much!
thorGT - Tue May 11 2010, 14:10 - link
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.
thorGT - Tue May 11 2010, 14:37 - link
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 - Tue May 11 2010, 14:47 - link
  (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 - Tue May 11 2010, 15:17 - link
    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 ;)
elcuco - Tue May 11 2010, 15:39 - link
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 @kde.org to it) and you also have my GMail.
- Aurélien - Tue May 11 2010, 16:09 - link
  Very good point. I haven't tested RTL support. I just added this to my list of things to check/implement.
Magnus - Tue May 11 2010, 16:27 - link
How does global menus work when using window focus following the mouse pointer?
- Aurélien - Tue May 11 2010, 16:46 - link
  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 - Wed May 12 2010, 3:20 - link
    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."
    - Aurélien - Wed May 12 2010, 10:56 - link
      Interesting solution, thanks for sharing.
Dirk - Wed May 12 2010, 3:12 - link
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 - Wed May 12 2010, 10:55 - link
  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 - Wed May 12 2010, 15:30 - link
    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 - Wed May 12 2010, 17:43 - link
      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 - Wed May 12 2010, 17:59 - link
        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 - Wed May 12 2010, 22:42 - link
        Don't want it - don't use it. And keep silent as many others want it.
        Dirk - Thu May 13 2010, 6:03 - link
        Says who?
        FrancescoK - Thu May 13 2010, 11:01 - link
        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 - Mon Aug 16 2010, 13:27 - link
        Probably the idea behind a single menu bar is to have the desktop like a big MDI application.
    - Aurélien - Wed May 12 2010, 20:29 - link
      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.
Adam - Wed May 12 2010, 3:18 - link
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.
furanku - Wed May 12 2010, 7:34 - link
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 - Wed May 12 2010, 11:04 - link
  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.
Andreas - Wed May 12 2010, 15:41 - link
@Dirk,
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...
Stefan Majewsky - Wed May 12 2010, 20:35 - link
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 http://majewsky.wordpress.c... 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 - Thu May 13 2010, 0:03 - link
  Yes, you will be able to query whether the global menubar is available with QMenuBar::isNativeMenuBar()
lelamal - Wed May 12 2010, 23:54 - link
Hey, thanks for sharing. I'm sure this is gonna be an awesome feature! I hope to see it implemented in Kubuntu 10.10!
mario - Thu May 20 2010, 15:37 - link
when will the patch land in qt trunk? or is it already?
- Aurélien - Thu May 20 2010, 17:38 - link
  No it's not in trunk yet. And it won't reach Qt until Qt 4.8 because 4.7 is in beta.
Yaohan Chen - Mon May 31 2010, 10:22 - link
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 - Mon May 31 2010, 12:08 - link
  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.
docidu - Thu Jun 03 2010, 3:44 - link
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....
Merlin - Mon Jun 28 2010, 22:46 - link
I've been waiting for this for SOOOO long!!!
will we be able to download it from kde-apps.org???
I would really like to get my hands on this right now!!!
- Aurélien - Tue Jun 29 2010, 14:10 - link
  This requires a Qt patch so it can't be made available on kde-apps.org. 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.
Thales Oliveira - Sun Jul 18 2010, 23:03 - link
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 - Sun Jul 18 2010, 23:05 - link
  sorry I wanted to say: KDE 4.5
  - Aurélien - Mon Jul 19 2010, 12:19 - link
    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 - Sat Jul 31 2010, 20:51 - link
      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,
      Thales
      - Aurélien - Wed Aug 04 2010, 0:16 - link
        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 - Wed Aug 04 2010, 1:33 - link
        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,
        Thales
        Aurélien - Wed Aug 04 2010, 1:49 - link
        Testers are always welcome. Especially checking applications behave correctly as some applications do weird things with menubars. The easiest way to test is probably through Kubuntu daily CDs. Give it a try and report bugs on Launchpad. You can learn more about this from here: https://wiki.ubuntu.com/Des...
        Thales Oliveira - Mon Aug 16 2010, 6:52 - link
        it finally worked! the gtk apps doesnt work at all, but anyway :)
strife - Mon Sep 06 2010, 20:01 - link
Hope this gets available for desktop kubuntu aswell and not just the notebook version!!!!
I want!
- Aurélien - Tue Sep 07 2010, 0:14 - link
  It is available for both versions, no problem.
Praveesh K P - Wed Oct 06 2010, 18:26 - link
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
Merlin - Tue Oct 26 2010, 20:24 - link
So tell me,
is the patch still going to get into QT4.8??
What news do you have about this?
Tks
- Aurélien - Wed Oct 27 2010, 17:14 - link
  Yes it is.
  - Merlin - Thu Oct 28 2010, 19:18 - link
    GREAT!!! :) "Native" support, finally!! :D (sad that so many months are still ahead... but will still be great:)))))
Zephyr - Sun Oct 31 2010, 3:30 - link
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:
http://forum.kde.org/brains...
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 - Tue Nov 02 2010, 2:23 - link
  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).
Zephyr - Tue Nov 02 2010, 17:52 - link
I see! That's great!
Thank you very much and keep rocking!
drja - Sat Nov 06 2010, 17:58 - link
Hi,
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 - Sat Nov 06 2010, 21:28 - link
  It is indeed a problem, but we haven't defined any workaround yet. Not sure what we could do to avoid that.
Antony - Fri Apr 29 2011, 13:39 - link
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?
Benji - Fri Feb 10 2012, 6:54 - link
Hi,
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 - Fri Feb 10 2012, 7:00 - link
  and that appmenu-qt plugin... will it come with kde or will we have to manually install it?! :(
  - Aurélien - Fri Feb 10 2012, 13:56 - link
    "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 - Fri Feb 10 2012, 13:53 - link
  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.
cturkel - Sat Jun 16 2012, 21:29 - link
I just installed this and wow! Awesome!
BTW anyway to change the fonts or font styles?
Ken - Mon Aug 06 2012, 8:38 - link
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 - Mon Aug 06 2012, 11:36 - link
  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 :(
  - Ken - Tue Aug 07 2012, 1:03 - link
    Ah, well I can't blame you.
    I've never done any KDE development before, but I thought I'd just peek at the code. I found this, but it hasn't been updated since 2008, so I assume it's the wrong place to look:
    http://lxr.kde.org/source//...
    Can you tell me where I would find the current canonical copy of the source code for the applet? I'd like to take a look at how it works. Thanks!
    - Aurélien - Tue Aug 07 2012, 16:34 - link
      Great to hear! The applet is hosted on Launchpad: http://launchpad.net/plasma... . You may want to get in touch with the Oxygen Appmenu developers as well: they started the necessary work to be able to run two applets on the same desktop.

(Comments are closed)