@romangg arguably our protocols used by KF5 clients shouldn't break. Though for things only used by Plasma, pragmantically it should be fine.

• Drop ShellClient
• Drop XdgShellV5
• Rename XdgShell classes to match the spec used in V6/Stable rather than trying to retrofit into V5

Drop ShellClient

You mean wl-shell, right?

yes

Should KWayland (Server part) be moved out of Frameworks into a Plasma lib?

That's a really good question!

Generally speaking, I would prefer to move KWayland::Server back into KWin and re-brand KWayland::Client to KWaylandClient, it's still a good idea to have wrappers that can be used by clients, though one could argue that setting blur region and so on can be completely encapsulated in KWindowSystem thus eliminating the need for client side wrappers.

Anyway, I would support both moving KWayland::Server into a Plasma library or directly into KWin.

or directly into KWin.

Moving into KWin will be better for us though as we wouldn't have to worry about keeping ABI and API compatibility.

Moving into KWin will be better for us though as we wouldn't have to worry about keeping ABI and API compatibility.

If we are a lib in plasma we don't necessarily need to worry about API/ABI either. It's somewhat lib dependent.
There are advantages of being separate as then the server side can be used for unit tests of kwayland-integration or whatever.

With regards to history, the reason it's a framework is so other frameworks can use it directly. We definitely do need frameworks to have a way to make some custom wayland calls.

I would say it hasn't entirely worked out as-is as KIdleTime, KWindowSystem and KGuiAddons all ended up having a plugin system where that plugin is in plasma anyway!

*if* we make kwayland plasma local (and I'm not entirely convinced either way), we will need to either:

• Expand KWindowSystem with everything p-f or any future app might need, adding in an abstraction layer for everything
• Expand QtWayland extension API (through either QPlatformHeaders or their half-done extension support)

Copying and pasting the result of the wayland mailing list thread "Problems in KWayland causes by API and ABI compatibility promises"

We had a meeting. It resulted in some final action decisions.
These will affect the kwayland folder in frameworks.

The meeting was attended by: Kevin Ottens, Vlad Zahorodnii, Aleix Pol, Myself, Benjamin Port who all approved the plan.

Protocols:

We make a new repo. It will contain just protocol XML files.

plasma-wayland-protocols - target is kdesupport.

Existing protocols remain exactly the same, just moved
New protocols follow upstream wayland-protocols naming scheme using the "zkde_" prefix

Client - short term:

We leave things unchanged.

Kwin tests will continue to use KWayland::Client as is, the upcoming fork KWayalndServer (mentioned in a bit) will stil use it.

If something comes up that requires an ABI break or new classes from client (XdgShell for example) we deal with it locally in the relevant repo as per the longer term plan.

We slowly migrate to the long term plan.

Client - long term direction:

If something is used in N places - we should abstract things in a high level API like KWindowSystem.

If it's used in 1 place, we go native with QtWayalndClientExtension and the generated classes.

Autotests for the server should use generated low-level classes, see for example the currently merged tabletmanager autotest. If we need something in kwin and KWaylandServer, we just do it in both.

Client will still have a KF6 library for doing super core stuff such as ConnectionThread, wl_surface, buffers etc. It won't contain all the extra protocols.

At KF6 we rename namespace and repo to KWaylandClient.

Server - short term:

We make a new repo. It forks existing KWayland::server classes from framework's kwayland + the autotests. This goes into kwaylandserver

put in workspace

no ABI/API guarantees, but released in sync with kwin

.so bumps each time

new namespace (i.e KWaylandServer)

Institute a complete freeze of the server folder in KF5

Server - long term direction:

Unit tests migrate to testing against just generated code for the extra protocols

Drop Interface suffix in class names.

Drop from KF6

Update from the sprint: We want to look into if we can fully deprecate KWaylandClient for KF6 and use QWaylandClientExtension everywhere. Current usage in KDE (searched KwaylandClient on lxr):

• • plasmashell protoocl for positioning and plasmashell
    • plasmashell and and dialog (of course)
    • Yakuake
    • krunner
    • ksplash
    • logout-greeter
    • latte (and shadow)
    • spectacle
• FakeInput
  • KDE Connect
• KWayland Integration uses a bunch of stuff for its plugins
  • idletime
  • keystate
  • kwindowsystem plugin uses blur, contrast, slide, shadow, plasma window management, plasmashell, shm
• KScreen uses dpms and output
• Oxygen shell, seat and pointer to get a serial for requesting a move
• the platformtheme uses surface, appmenu and our decoration protocols
• KInfoCenter lists every interface and information about seats, keyboards and outputs by listening to the registry
• taskmanagement by the things that do task managemnt
  • plasma phone components homescreen and taskpanel
  • libtaskmanager
• powerdevil dpms
• xdg-desktop-portal-kde
  • plasmawindowmanagement
  • output
  • fakeinout
• datatadevive by KWIn and klipper
• Of course KWaylandServer and KWin tests which should move to generated code according to the above plan

Also compare with the future plan for our custom protocols:

appmenu.xml 

    WIP upstream: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/52

blur.xml 

    WIP upstream: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/43

contrast.xml

    Similar to Blur, but not upstreamed ???

dpms.xml

    Maybe should go to XDP? Maybe protect it?

fake-input.xml 

    Used by XDP and KDE Connect at least (bshah: late comment: Phosh also have similar protocol, maybe it makes sense to "upstream" this?)

fullscreen-shell.xml 

 Unused

idle.xml 

    There's a similar thing being upstreamed

keystate.xml

    Fine

output-management.xml, outputdevice.xml 

    Fine

plasma-shell.xml 

    :-(

    TODO David shall investigate if we can kill some parts

plasma-virtual-desktop.xml, plasma-window-management.xml 

    Fine

remote-access.xml 

    To remove

screencast.xml 

    Fine

server-decoration-palette.xml, server-decoration.xml

    Fine

shadow.xml

    Fine

 slide.xml 

    Fine

surface-extension.xml 

    To remove

text-input-unstable-v2.xml, text-input.xml 

    To removed when something else offers the functionality

wayland-eglstream-controller.xml

    To be removed and moved to KWin

I think I missed some, so next try:

Current usages of client library outside of kwayland, kwaylandserver, kwin tests

• AppMenu: 1 (plasma-integration) -> Scanner
• Blur: 1 (kwayland-integration) ->Scanner, also potentially in windowsystem
• Compositor: 1 (kwayland-integration, to set region for blur)
• ConfinedPointer: unused
• Contrast: 1 kwayland-integration: -> to kwindowsystem directly
• DataDevice and friends: 2 (kwin xwl, kscreenlocker test creates one but doesn't do anything?): Kwin could use scanner output but note that klipper already uses scanner for that
• dpms: 2 (libkscreen and powerdevil) -> ?
• fakeinput: 2 (kdeconnect, kwayland-integration for a idletime test), xdg-desktop-portal-kde -> still need wrapper somewhere?
• fullscreenshell unused
• idle 1 (kwin) -> scanner
• idleinhibit: unused
• keyboard: kinfocenter
• lockedpointer unused
• output 3, libkscreen, libtaskmanager (screencasting), xdg-desktop-portal-kde
• outputdevice: 1 libkscreen
• outputmanagement: 1 libkscreen
• plasmashell many (latte, plasma-framework dialog, yakuake, spectacle, kscreenlocker, kwayland-integration, plasma-phone-components, krunner, logout greeter, plasmashell): we want plasma to use layershell but there seems also to be a need for some apps for positioning
• virtualdesktop: latte, libtaskmanager
• plasmawindowmanagement: latte, plasma-phone-components, libtaskmanager, xdg-desktop-portal
• pointer: oxygen -> scanner -pointerconstaints: unused
• pointergestures: unused
• relativepointermanager: 1 kwin wayland backend
• remoteaccessmanager: unused
• seat: 2 oxygen, kinfocenter
• serversidedecoration: plasma-integration
• shadow: latte, kwayland-integration (maybe could use kwindowsystem shadow?)
• shell: unused?
• Shmpool: 3 (latte, kwayland-integration, kwin wayland backend): maybe to kwindowsystem since latte seems to use it for shadows (see above), kwin manually?
• subcompositor: kwin
• subsurface: kwin
• textinput: unused
• touch: unused
• xdg-decoration-manager: unused
• xdgexporter/importer: unused
• xdgoutput: unused
• xdgpositioner: unused
• xdgshell: kwin

So we have a bunch of client classes that are unused, no problem deprecating those. Some things are only used by kwayland-integration, they could move to the relevant frameworks and use qtwaylandscanner. In general most things are used in only one or two places with very few exceptions in three. If we can't find a high level api for it, maybe we could still use scanneer output for it (set the N from above a bit higher). But there seems to be a need for wrappers for the plasma specific protocols which are used in a bunch of places, but maybe such things could also live in plasma itself instead of frameworks? I also wonder if instead of having X plasmawindowmanagement users, if they could use libtaskmanager instead.

(post KF6 meeting 2021-05-22): there is a solid plan in motion, moving to "in progress" on the KF6 board (no real blockers for the release).

Some porting:

https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/463
https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/58

Oxygen shell, seat and pointer to get a serial for requesting a move

Breeze uses QWindow::startSystemMove for this: https://invent.kde.org/plasma/breeze/-/commit/6d83b0454

Remaining users of KWayland:

plasma-framework
xdg-portal-test-kde
krfb
kpipewire
kscreenlocker
kwayland-integration
kwin
latte-dock
libkscreen
plasma-integration
plasma-mobile
plasma-nano
plasma-workspace
xdg-desktop-portal-kde
selenium-webdriver-at-spi
yakuake

Except for yakuake and krfb all of those are within Plasma, so if we do not manage to port all of them away in time for 6.0 we could move kwayland to Plasma

I will fix krfb, I know there are pending patches for yakuake to port to layer-shell which are ready to go when it can rely on Qt 6