Problem with KDecoration3

Development
21

I don’t think you would need the windowId.

There are essentially two use cases in your decoration and they can likely be both done in the new base decoration.

One is the two occurrences of code copies from the Breeze decoration (e.g. getting a correct geometry).
This sounds like something the base decoration should already do.

The other use case is updating the app menu model on certain property changes.

With the new interface for exposing the D-Bus properties which @zzag linked to earlier, this could likely be done by connecting to the change signals of those new properties.

22

At this point, it seems to me even easier to patch KDecoration or Breeze to turn the button with the appmenu into a QMenuBar.

25

The new properties (DecoratedWindow::applicationMenuServiceName() and DecoratedWindow::applicationMenuObjectPath()) should be available in KDecoration 6.3.2.

1 Like
26

Thanks, however to me it would seem much more straightforward, and general, to have a method that, on both X11 and Wayland, returns a unique identifier for the window. On X11 it’s obviously the WId, on Wayland it could be wl_surface or some more Plasma-specific object.

27

It might look more straight forward from the point of view of changing less client code.

However, from a maintenance point of view of both framework and decorations, it makes more sense to do window system specific things in the base implementation instead of requiring each decoration to copy&paste the workaround for base limitations.

28

That’s not how things work on Wayland. You won’t be able to look up app menu dbus information by wl_surface’s wl_resource. A decoration theme cannot also implement the appmenu protocol by itself.

29

Can you explain better what you mean? The way I see it, but I may be wrong, if an object is called ‘decoratedWindow’ it should bring the properties of the window it represents, including something unique to identify it.
For example, QWindow::winId() on X11 returns the X11 window identifier, on Wayland it returns the QT window identifier. I think something like this makes sense.

30

Mine was an example, I am not saying that it necessarily has to be a wl_surface, probably a more abstract object makes more sense. Exploring the current appmenu implementation for Plasmashell in some places it is necessary to identify specific window. This shows that a unique identifier is a common requirement, even in Wayland.

31

Again, that’s not how Wayland works. There are no global window handles like on X. If you have concrete examples where you must have access to such a thing, we can discuss it; otherwise we are wasting our time discussing hypothetical usecases. For the original problem, you should have all the data to make LIM work with KDecoration3, window ids are not required.

32

I just have given you a concrete example where it is necessary to go back to the unique Wayland window.

It doesn’t matter anyway, this decoration works again, now just do me the favour of not touching anything else on X11 for the sole purpose of breaking backward compatibility.

33

Wow, that’s so nice of you :confused: The app menu in plasmashell gets the app menu dbus information from kwin, it doesn’t need window ids either. Window ids on Wayland, in general, are of no practical use; there are some internal ids but they are of no use as on X. Anyway, good luck with your decoration theme.

34

In one place the window ID was used to by a hack/workaround (copied from the Breeze decoration) to determine the correct window geometry through calling low level XCB API.

This can of course be implemented either the same way or better in the base decoration API and shared between decorations instead of copy&paste of the workaround.

In the other case it was used for a hack/workaround of behavior in the LibreOffice launcher to become aware of new values regarding the D-Bus interface for menu data.

Again either the workaround or a better implementation can be done in the decoration base API and changes to such values be communicated via signals.

Essentially moving these display protocol specific bits into the library shared by decorations when possible.

Much like other bits of platform differences are inside of Qt or KDE addon libraries.

If there is a need for platform specific code that is not yet covered by the base API it is often worthwhile to implement the support code there.

On the application side developers commonly use a “rule of thumb” to put code into a shared library when more than one application starts having a need for it.

A new major version of a different already shared library or base API can then more easily incorporate such additions at an even wider shared layer.

For example KStandardDirs being moved/reimplemented as QStandardPaths when a major version change allowed API to be removed from the respective KDE library.

35

I understand your argument but it seems to me that there is too much confusion.

The very fact that the need has now arisen to expose properties that weren’t before because some random user (me) realised they were needed should make you think that instead you need a class throughout Plasma that has all the properties a window can have.

With X11 the problem didn’t arise because knowing the id you could know all the properties of the window, anywhere in the code, without worrying if the developer had remembered to expose a particular method or property.

Maybe it would be worth thinking about this, and maybe don’t accuse someone who has even offered money to implement LIMs upstream, of wasting your time.

36

I don’t want to be rude, but having offered money (and having also gathered the support of other users who offered their money) to implement LIM directly in KWin and KDecoration, to be told that I am wasting your time is rather unpleasant.

37

Please try to read zzag’s post in good faith. He didn’t say you waste HIS time but lets not waste OUR time (aka lets not talk past each other).

You have had multiple developers trying to help you, your effort to improve KDE is clearly appreciated. I appreciate your effort here too (thanks!), but I think your tone here is off.

Again, please try to assume good faith. Otherwise I am going to close this thread.

2 Likes
38

“to be told that I am wasting your time is rather unpleasant” it’s a mischaracterization of my words. Just to be clear, I did not say that implementing LIM is a waste of time, and I actually would support such upstream proposals.

In order to support locally integrated menus on Wayland, kwin must tell the decoration the information about the dbus service name and object path of the menu, the decoration won’t be able to look up such information by itself. Window ids are not really a thing on Wayland. To be fair, there are ids like xdg-foreign handles but they are tailored for specific use cases and are unsuitable for generic usages due to different philosophy behind Wayland. And rather than invest even more time in such a discussion about window ids (like add window ids for wayland windows), it can be spent better other ways (like adding missing APIs that are needed to implement LIM).

The new KDecoration API should provide a platform agnostic way to get the information about the app menu, it should work both on X and Wayland. As for missing APIs, the KDecoration API is driven mainly by the needs of Breeze decoration. It currently has no support for LIM so we have been unaware of what is needed to implement them until recently. Maybe more things are missing… If so, the right thing will be to file feature requests.

1 Like
39

Perhaps there’s a misunderstanding here, it’s not that I’m fond of WId, the point is to be able to identify a window uniquely anywhere in Plasma’s code, being able to know all of its properties (unless, for some special reason, you have to explicitly hide some of them, but here we’re talking about code running inside the compositor).
This can be done in various ways. This would avoid having to invent some stratagem from time to time, or having to constantly modify classes to expose certain properties that were not exposed before, because at a certain point you realise that you need them.

40

This is only possible inside KWin, it is the only place that aggregates all client state data.

It has a KWin::Window object for each client window.

KDecoration3::DecoratedWindow is the decoration side “view” or “proxy” of that.

Most values are implemented like this

#define DELEGATE(type, name, clientName)   \
    type DecoratedWindowImpl::name() const \
    {                                      \
        return m_window->clientName();     \
    }

#define DELEGATE2(type, name) DELEGATE(type, name, name)

So a getter of the “view” is just a forward to a getter (possibly with a different name) of the actual data object.

Any information that KWin has on a client can be exposed through this while avoiding to expose internals that KWin wants to keep control over.

If it is really required it should be possible to add a generic property getter, something like

QVariant DecoratedWindow::windowProperty(const QByteArray &property)
{
    return m_window->property(property);
}

in case any of the Q_PROPERTY of Window is not yet accessible in DecoratedWindow.

41

Indeed, KWin::Window was my first attempt.