At first I have to thank all of you for the great work you're doing here. Plasma 5 looks stunning!!

But there is one thing I am really missing from KDE 4 - the global appmenu.
I know that this is just partly a decision of the design-team - but are there plans to implement a global appmenu via appmenu-qt
in plasma 5? (http://www.webupd8.org/2013/02/how-to-e ... title.html)

I think it would be really great to have that as an option - because that is what KDE is about, right?! - having options.

What do you think about an optional global appmenu in Plasma 5?

I have it as an option in systemsettings (but have not tested)

It may not be available in Arch yet or you haven't added a needed package, maybe appmenu-qt5

for further reading:
https://launchpad.net/appmenu-qt5
http://osdir.com/ml/scm-fedora-commits/ ... 11379.html
viewtopic.php?f=289&t=121888

Thanks for your fast answer and the informations.

Can you tell me where the Option is located in the systemsettings? I actually have appmenu-qt and appmenu-qt5 installed but I dont find any option about the appmenu.

In KDE4 it was System Settings > Application Appearance > Style - but there is no Option right now.

further investigating shows that as of 1/13/15 it was not functioning and needed to be rewritten so I'm not sure where it stands but I can say that even though the I have the option it does not work for me see https://bugs.kde.org/show_bug.cgi?id=341071

option is in systemsettings -> application style -> widget style

found this on the Arch forums https://aur.archlinux.org/packages/appmenu-qt5/

You need to add:
export QT_QPA_PLATFORMTHEME=appmenu-qt5

to your zshrc (or bashrc if you are still in the 80's) for appmenu to work!
Just test it and it works.

starting to wonder if the appmenu-qt5 is for QT 5 apps running under KDE 4, maybe someone more involved can explain

Oh. I didn't see this new comment...But:

As I seem to be "still in the 80's": Changed my ~/.bashrc and it doesn't appear in the systemsettings. So maybe I just have to wait until it's rewritten. Thx for your effort.

I'll list all the relevant pieces so someone else can take this on.

There is a library for sending/receiving a menu over DBus

https://launchpad.net/libdbusmenu-qt

This builds on Qt5, I don't know if it works

Then we need a Qt plugin that makes all apps take their menu and send it over dbusmenu-qt. This is called appmenu-qt

https://launchpad.net/appmenu-qt5

This doesn't build.
Naturally you might also want the qt4 and gtk versions.

A small daemon registers for listening to apps menus and is a common point for connecting the UI with all the windows.

This is part of Plasma-workspace in the subfolder appmenu.
This only builds if dbusmenu-qt5 is found.

This daemon certainly loads, if we then qdbusviewer on org.kde.kded5 under the path KAppmenu.

In theory at this point we should be able to validate things are working by calling the showMenu method which should show a popup.

Currently for me it does not work. DBus-monitoring shows no menus being sent.

Finally we have the applet:

https://launchpad.net/plasma-widget-menubar

That isn't worth even looking at until the rest is working.

-------

I'm happy to help with things but this is a research and investigation challenge as much as a coding task.

Thank you for the initial research, David!
So, if anyone would like to help make appmenu work in Plasma 5, here's your chance!

Canonical jumped out of appmenu, see https://bugs.kde.org/show_bug.cgi?id=341071#c9

I did some research into GMenuModel.

From the GMenuModel code
"The D-Bus interface that is used is a private implementation"
http://www.freedesktop.org/software/gst ... orter.html

From a quick look it does /nothing/ in GMenuModel that can't be exposed as an AppMenu.
My working theory is it's been done solely to annoy me.

That Canonical Qt code code doesn't help solve much..

It's a thin wrapper on top of GMenuModel, presumably because the DBus spec is volatile.

Rather than using the lovely plugin interface of QMenuBar it's an explicit API, it seems they're ignoring QWidget stuff completely, just have QML.
On top of that, rather than using QtQuick.Controls.Action and exporting things properly they've made up their own API which is somewhat questionable. They've then shoved in some Unity stuff on top of it in the lib rendering which won't help us use it.

What do you want? Protocols are sooooo 90ies - libs are the cool new toy m(

However, gobject is currently a complete no-go for KWin.
It requires the glib event dispatcher to work properly and leaving aside the "oh, an X11 error - I abort"[1] attitude, its other attitude to randomly "I'll do this the next event cycle" was rather troublesome.

Leaving aside that appmenu has (had?) *slight* issues w/ dynamic menus (ie. when the structure changed after creation) and I never really liked handing out deep action structures (ie. not only the menubar, but also the menus) to the public (securitywise - gnome global menu used X11 properties) and, leaving aside the QWidgetAction problem, this turns a sync UI into an async one - if the client isn't prepared for that: boom!.... where was I? ...
Ah, yes: leaving all this aside, GMenuModel is a proprietary feature, done the GNOME way.
We can either run after them (and after the recent "**** on the NETWM we basically control - we want CSD, somehow hacked into gtk+", I'm a bit reluctant here) or specify a *protocol* ourself that can then be implemented by everyone w/o external dependencies. It will however mean a break and "3rd party" clients (FF etc.) will either have to take sides or implement both. *sigh* /rant

[1] Yes, the WM and compositor should really rather grab the server around every X11 call and XSync as much as possible...
google for "Gdk-WARNING **: The program received an XWindow System error" (but not as string)

I hope this gets working soon. I love KDE for they way it seamlessly integrates the terminal and file browser, as well as a ton of other reasons. But I really, really love global menus for the screen real estate they save. It's a shame that at this point I can only have one or the other. I wish I could help with the project, but I am wholly lacking in coding skills, so all I can do is beg.

I surely hope this will be fixed in some way. I'm still on KDE 4.14 (Debian testing), but I already noticed that applications which use Qt 5 (like VLC) aren't working with appmenu (that's somewhat unrelated to the above, since Debian doesn't have appmenu-qt5 altogether yet ). But it would be annoying if Plasma 5 won't get this feature, since I use it a lot.

https://bugs.kde.org/show_bug.cgi?id=341071#c9

I too really hope it will be fixed, it's a feature I'm really missing.

Likewise, I'm trying to get a Mac user to switch, and this is one of the mandatory things for them.

I can't say I disagree either, considering there's going to be a panel anyway, it saves some screen real estate when you can hide the menu in the app.