This Week in Plasma: Post-Release Polishing - KDE Blogs mentions “Consider it a reminder for everyone still on X11 to try the Wayland session again, because the X11 session receives almost no testing from developers anymore!”
Hi! Feature requests for KDE products are handled through the KDE Bugtracking System. The Community Wiki guide to getting setup and submitting tickets is located here: Get Involved/Issue Reporting - KDE Community Wiki
For what it’s worth, I noticed that several of the closed issues on that project’s repository mention using an alternative tool - GitHub - 2e3s/awatcher: Activity and idle watchers - which I would have to imagine is a pretty common need, if the aw-watcher-window-wayland tool is incompatible as-is with the default display servers for the two most common FOSS desktop environments.
Code on the KWin side (script/plugin) detects change in user activity and sends that to one, and only one, recipient.
If KWin provides an API then any client can monitor activity changes.
The watcher already seems to have a “Web API” and QML (which KWin uses for scripting) has a component for making calls to such API.
So in theory a KWin script could already notify the watcher about things like windows becoming active, etc.
More sophisticated tracking, e.g. mouse entering or leaving a window, might require deeper access to KWin internals but might still be doable as a plugin.
I am considering this as a (push-based) API too But perhaps a “KWin mechanism” would have been clearer.
More sophisticated tracking, e.g. mouse entering or leaving a window, might require deeper access to KWin internals but might still be doable as a plugin.
As long as KWin notifies the active window correctly, the key and mouse presses can be approximately associated with the window. More accurate tracking would be nice but not critical.
I haven’t done any KWin scripts myself so this is mostly educated guessing.
From the API docs it looks as if there is a list of all windows/clients, signals for when windows get added or removed.
There is a property for the activeWindow which should signal when it changes.
There is also a windowActivated signal.
Each window should also know if it is active or not, at least I see a active property in the KWin::Window object.
That object also has a caption property and desktopFileName should provide the application it is from.
The QML API for making REST API calls is XMLHttpRequest but I have not worked with that either.
Apparently they even created a D-Bus interface to call from their KWin script.
That is of course even better since that is user local, unlike the REST interface.
I am bit puzzled though that they are only connecting to windows that have become active after the script has been loaded and not to all already existing windows.
But maybe that is part of why it is, as you said, yellow status
But perhaps a “KWin mechanism” would have been clearer.