-> updating the title!!!!! !???!!

It's not that wtf like it reads at first. It doesn't read its own name property but of another window that is being screenshotted

kpasswrdserver -> watch windowRemoved (won't work on wayland - also why?)

Password requests are associated with a window ID. While a (non-modal) password dialog is shown, if the window goes away (e.g. user closes webbrowser window) the dialog is deleted. No point in asking a password for a window that was closed meanwhile.

Why can't wayland offer a way to be informed that a window has been closed? How can wayland be the solution to all problems if it doesn't have basic things like that? :-)

It doesn't read its own name property but of another window that is being screenshotted

That makes more sense - I like how spectacle already has the multiple backends route and this is already encapsulated.

kpasswdserver
How can wayland be the solution to all problems if it doesn't have basic things like that? :-)

Because it (deliberately) lacks the even more basic thing... knowing about windows from any other client.

The maximum one can do is set a transient parent, but even that is a laboured process with auth-tokens and a second communication channel. With the existing spec there, at most you can set that once, but there's no update signals.

We can do solutions at a plasma level, but it might prove easier to refactor this to work in other ways.

Good thing to tackle this. The separate kwayland-integration plugin always felt weird to me. I currently don't have an overview on KWindowSystem so I can't really comment on your analysis and proposed split but if you think it should be done like that let's move forward with it. What are the next steps?

Without knowledge on how such splits were done in the past could we start by moving code into separate repos in workspace and make Plasma depend on this incrementally instead of the functionality in KWindowSystem? And then move these repos back into Frameworks each as separate framework after everything has been split up.

We wanted to split up KWayland and move the server-part into Plasma to be able to iterate faster on KWin. Is this something to consider for the task here?

The separate kwayland-integration plugin always felt weird to me.

KWindowSystem is a tier 1 framework so it cannot use KWayland directly.

@octofox
That's the current state for KF5, but do you agree it's a weird thing that we want to get away from?

The only things in tier 2 that currently use KWindowSystem are:

• KCrash (for something that's X11 specific anyway)
• KNotification for SNIs (which I don't have a complete plan for)

If we can resolve the last one in a nice way, then we can bump KWindowSystem (or KHighLevelWindowStuff) up a tier and it simplifies everything.

What are the next steps?

Next step at this phase are trying to identify which KWindowSystem things:

• are actually used in places where abstraction makes sense
• actually can be abstracted
• if there's anything fundamental that should really just be in Qt
• porting things, where possible, to use Qt API instead of KWindowSystem (like I did in D26159)

KNotification for SNIs (which I don't have a complete plan for)

That would be resolved if my plan to kill KSystemTrayItem in favor of QSystemTrayIcon works out

In T12413#216931, @davidedmundson wrote:

@octofox
That's the current state for KF5, but do you agree it's a weird thing that we want to get away from?

Yes, having two wayland platform plugins for kwindowsystem seems to be weird, but unfortunately there is no other way around it given current kf constraints. Also, this maybe doesn't add anything to the discussion, but the in-tree plugin doesn't redirect anything. KWindowSystem has an in-tree wayland plugin because KWindowSystemPrivateDummy::compositiveActive() always returns false, but we want it to return true on wayland. It just so happens that KF5WindowSystemKWaylandPlugin (from kwayland-integratin) comes before KF5WindowSystemWaylandPlugin (from kwindowsytem) when QDir::entryList() enumerates entries in plugin-dir/kf5/org.kde.kwindowsystem.platforms/.

I can't comment on the split thing because I haven't given any thought to it yet. But perhaps it will be worth to have KX11 or something.

Sprint notes:

People are on board with the proposal. There's a better way to phrase it:

Handling Your Windows - > should be a high level multi-platform code - we provide only what's missing from Qt
Handling other program's windows -> should be in relevant low level frameworks and not abstracted as it doesn't work

Solid subtasks:

• KKeyServer - the two usages in krita / wacom KCM can be ported to KGuiAddons ksequencerecorder

Remaining usage is actually X11 only.

• We want a high level abstraction about startupIds that wraps KStartupInfo and works on wayland. This will have a lot of fall out

We can start this now. Need to check with @apol on this.

• KXMessages can be made private, it's only used internally and a dead feature in kwin/kstart
• we should deprecate

KWindowEffects::windowSizes ( const QList< WId > & ids )

• KWindowEffects - should use QWindow* instead of WId

(after splitting)

• highlightWindows doesn't belong in this class, it's not about applying an effect to your window, lets make a new approach in kwin and taskmanager (that works on wayland)

KXMessages can be made private, it's only used internally and a dead feature in kwin/kstart

Can we remove it in kwin now?

KWindowEffects - should use QWindow* instead of WId

Done.

highlightWindows doesn't belong in this class, it's not about applying an effect to your window, lets make a new approach in kwin and taskmanager (that works on wayland)

Done

Something we could relatively easily do now is move (i.e. copy+deprecate) some of the X11-specific functions in the KWindowSystem class to a new KX11Extras class

Candidates could be e.g. compositingActive, forceActiveWindow, activeWindow, stackingOrder, etc

https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/72

Another thing would be "renaming" KWindowInfo to e.g. KX11WindowInfo

I went through the users of KWindowInfo. The vast majority of usages in apps (i.e. not Plasma) is for virtual desktop info. That's only implemented on X11 anyway

KKeyServer -> KX11Keys or KXkbKeys ?