Is this proposal for porting to wayland/plasma 6 or upstreaming it to KDE ?
porting to Wayland (but also X11) and upstreaming.
Menwhile, 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.
After a year and a $1000 offer, no one took this request seriously.
It only looks that way because the discussion was spread across several threads.
The KDE side of this has since then moved quite a lot with API for accessing the D-Bus application menu interface of a window’s associated application being added to KDecoration
Is is of course possible that decoration developers haven’t picked this up yet, e.g. if that version if the library hasn’t arrived in their distributions yet.
What is less clear is whether the data is already correctly exported by applications, especially GTK based ones.
Any changes there would also not be visible here.
1 Like
This is the only thread in which money was offered.
That inclusion in kdecoration was done because of my report. Neither before nor since then has anything moved. Moreover, an inclusion that I did not need and is not sufficient to implement the interactive whiteboard anyway. Moreover, since the developers of kdecoration are the same developers as the developers of the default Plasma decoration, I don’t understand your point. They could have implemented it in their own decoration. But they have no intention of doing so it seems.
Therefore, as far as I am concerned, I withdraw the offer.
Doing a recap of all the threads would be useful to push the issue again to attention: there are so many posts in the forum that many of them may never reach developers’ attention; it might be that some developers do not even look at the forum, meaning that one needs to build a detailed report of all the requests and objectives to gain some traction and provide something that can be shared with other developers.
Excuse me Samuele, but this post is in the “development” / “sponsored work” section. That should be exactly where developers look. You can’t ask me to go around the whole forum looking for them.
True, I was simply pointing out that discussion had been spread across multiple topics and in some of those there was progress toward getting this addressed.
Excellent, so it must have been taken serious, no?
That is unfortunate, of course.
With the data now being accessible by decoration authors it will need them to port to the new API.
These decoration developers might not have been aware of the bounty or currently not have time to work on this.
Not sure what the interactive whiteboard is but the exposed information should allow the “locally integrated menu” part of the topic at hand.
I.e. decoration developers got access to D-Bus service name and object path through which the application associated with a given window has exposed its “global menu” data.
The default decoration might be kept simpler on purpose or nobody has yet attempted to expand its functionality.
However those decorations which already have support for such a menu can, since the API addition, conveniently get the D-Bus access information instead of having to extract it with methods that might or might not work in both X11 and Wayland.
I have long since linked this thread on the other thread where the LIM was discussed but it has not helped. I don’t know what else to do.
I don’t agree so much when you say that the default decoration should not have LIM. Certainly not enabled by default (as neither is the global menu by default in Plasma), but it could have it.
In any case, let’s cut to the chase. You are a KDE developer, let others know that there are people willing to donate.
I guess the best thing at this point is to get in touch with decoration developers who have already supported LIM, just not in cross-display-system way now available.
They can now make their implementations work on X11 and Wayland and even get rid of custom code in the process.
Not adding such a feature by design is just one of the possibilities.
Absolutely.
It could very well be that a respective merge request would be welcome.
Might be a good idea to check with the respective maintainer first though.
I don’t have any more contact to decoration developers than any other user 
Well, it seems that someone is actually working on it!
Nice!
As expected the new API makes it work on X11 and Wayland.
Other decoration developers might follow and port away from their custom code as well.