A bit of Unity in KDE: Locally integrated menu and Hud

Brainstorm
21

I think LIM and global menu applet are mutially exclusive. Of course you can have both on your desktop but it would be redundant.

22

I mean: I found some apps do not correctly serve the global menu; or at least I remember reading that not all of them expose their menu. I would use just one of them at a time, but if some work is done to provide LIM and apps are encouraged to make this work, I suppose this would benefit the global menu too.

23

All GTK apps don’t support global menu, currently.

24

Is it because they are not exposing the menu to the system in a standard way?

25

Not true, all gtk2 and 3 support global menu on X11 (or Xwayland).

26

They do via dbus. The problem is Wayland. If you run a gtk app with Xwayland the global menu works fine.

1 Like
27

LIM and appmenu applet are both based on the same dbusappmenu interface, so if an app expose its menu, it works both on LIM and globalmenu.

1 Like
28

Well I have a Wayland centric viewpoint, sorry 424485 – GDbus-DBusMenu-Proxy does not work for GTK Wayland apps

29

This means that if the improvement you requested (Locally Integrated Menu and krunner-appmenu: an offer) gets done, it will benefit both LIM and global menu. That’s what I was trying to understand. Thank you

1 Like
30

material-decoration with LIM has been upgraded to Plasma 6.3.

Plasma 6.3 has broken compatibility with the LIM.

LIM relied on the windowId() method of KDecoration2::decoratedClient, which is now unavailable in KDecoration3::decoratedWindow.

To replace it, we rely on the internal API of KWin::X11Window, in the hope that the KDE developers will stop making their Desktop Enviroment progressively incompatible with X11.

31

In practice, dragging Gnome CSD windows is easier given the fact that the drag region is taller. It is also better defined because on KDE the titlebar is blended with the window chrome, where the drag behavior is not at all guaranteed. Windows has the same problem: you think you’re dragging the titlebar but nope your cursor is actually in the app region and you’ve either clicked on something or the drag motion failed.

The UI consistency arguments no longer apply either, since many if not most modern apps dispense with empty titlebar, the server titlebar can clash with the app UI etc. The need to see the app title is arguably outweighed by vertical space considerations in the vast majority of cases.

So the way forward I think is away from empty titlebars and toward something “like” CSD (whether it’s plain CSD or some server-side solution, eg. putting the menubar in titlebar like in this proposal or even overlaying the transparent drag region+buttons on top the app, which would fix stuff like CSD apps that can’t be assed to follow the platform theme).