Bug 442662

Yakuake having issues should be fixed, but not with this approach.

Wayland is different, trying to shoehorn that into the exact same abstractions simply won't work. 

Lets split this up as individual bugs on yakuake.

(In reply to David Edmundson from comment #1)
> Lets split this up as individual bugs on yakuake.

There are already individual bugs on Yakuake - this ticket was to upstream all the issues that arise from Yakuake depending on KWindowSystem signaling for several features.

@Firlaev-Hans - here is a summary of a discussion I had today on #plasma:kde.org:

----8<----
David Redondo (regarding the activeWindowChanged() signal): The signal will never be more useful than QGuiApplication::focusWindowChanged because on wayland the only thing the application can know if it's focused or not.
KWindowSystem was never necessary to know if you have focus

zzag: it's a bit difficult. due to kwindowsystem being x11 oriented historically, activewindowchanged can be used to monitor the active window [me: this is a big no-no in Wayland]
but yeah, with wayland, kwindowsystem makes sense only for things such as setting blur, server side drop shadows
i.e. manipulating your own windows
if you want to manage foreign windows, use libtaskmanager
we need to deprecate and split a bunch of stuff for kwindowsystem in kf6, but due to being busy with other sutff, I don't think that anybody has started work on it
----8<----

So, yea - Yakuake will either have to find cross-platform way of doing things that it relied on KWindowSystem for before (e.g. QGuiApplication::focusWindowChanged) or implement two different code paths for X11 and Wayland for more complicated things. As an example for this approach, I looked at the MR in https://invent.kde.org/plasma/kactivitymanagerd/-/merge_requests/16 , where KActivityManager's VirtualDesktopSwitchPlugin was modified to test `KWindowSystem::isPlatformX11()` and if so use KWindowSystem, otherwise use a Wayland-specific implementation.