Unfortunately, the documentation on the porting from KDecoration2 to KDecoration3 is very deficient.
In particular I find myself with the lack of windowId() in KDecoration3::DecoratedWindow which was previously present in KDecoration2::DecoratedClient.
What is the correct way to proceed now?
@krake hi, any idea? Thank you!
You have windowClass that might suit you.
What is the use-case of windowId ?
This is X11 specific.
I’m trying to mantain the material decoration with Locally Integrated Menu. It needs the windowsId. How can I exted DecoratedWindow to reimplement windowId?
windowClass is not univoque, if I’m not wrong.
You might need to git the window id by yourself: How to get an X11 Window from a Process ID? - Stack Overflow
Mmmh but DecoratedWindow has not a method for the Pid. Also the same Pid can have more than one window.
I’m trying to understand how kdecoration2 windowId() did work but I’m failing miserably.
The Pid is easy to get from cpp, or QCoreApplication.
Can you please explain what exactly you need windowId for? To query the dbus service name and object path of the menu? or something else?
(this is not yet ported to DecoratedWindow but I ported it locally)
In Decoration.cc and AppMenuButtonGroup.cc @zren uses windowsId from DecoratedClient. I would get the WId again as KDecoration2 did.
material-decoration/src/AppMenuModel.cc at 216be20f43362c05e46f1a973f1ecaca74e4d197 · guiodic/material-decoration · GitHub okay, so the only missing bit is the dbus menu stuff. We will expose dbus service name and object path, the app menu model will need tweaks. WM_CLASS should be already exposed. With those two new properties, I believe that LIM will work with native Wayland Qt applications too.
The code in Decoration.cc that uses window ID has apparently been copied from BreezeSizeGrip.cpp
Assuming that Breeze has been ported to the new API, its current version could be the solution for that part
Thanks but isn’t there a more immediate method? I’m just maintaining this decoration for X11 while waiting for someone to implement LIM in KDecoration so any decoration can use it. My idea was to extend KDecoration3:DecoratedWindow to restore windowId, but I don’t quite understand where KDecoration2 gets windowId from.
Any suggestions are welcome 
Expose application menu dbus interface info (!80) · Merge requests · Plasma / KDecoration · GitLab adds application menu dbus interface path properties. I’m not a fan of adding a windowId property because it is going to work only for X windows. Those dbus interface properties will be needed in either case.
QWindow is not X11-specific. If I had the QWindow object related to decoratedWindow, it would solve the problem.
Please file a bug report at bugs.kde.org with all the use cases that you need windowId for because I’m confused now.
Before that I would like to have a suggestion on how to get around the problem. For example if there is a way to go back to the DecoratedWindow’s QWindow from there I would get the winId.
Maybe @zren who is the original author of that decoration could give me an idea…
Before that I would like to have a suggestion on how to get around the problem
You use those new properties instead of looking them up yourself using the win id. You will need to adjust the app menu model, but it should a very trivial change
For example if there is a way to go back to the DecoratedWindow’s QWindow from there I would get the winId.
QWindow and GdkWindow are client side objects. KWin has no access to them because of address space isolation.