That was merged, and this is basically done in Plasma 6 now.

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

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

Remaining users of KWayland:

From the QWheelEvent docs:

https://invent.kde.org/plasma/kdecoration/-/commit/4091b18bfef5e1ff8f2924ad18917ebbb14987b0 changes the deprecated posF() to position().

This proposal will be implemented if and when https://invent.kde.org/plasma/kscreen/-/merge_requests/152 is merged!

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

Some porting:

This was fixed by me a few plasma versions ago

late to the party question.
is this issue still pursued?
when I got my new laptop I noticed that it the new archlinux install UIs seemed too small.
my last laptop was an old 15.6" 1366x768 .
my new one is a 13.99' 1080
after a lot of changes I arrived at using 150% scale in kde display setting.
but I still have a lot of questions.

If you don't want to maintain an option in the UI - cause the amount of people using it - why not just add it to the config file. I would say, that the default does not really matter. Both solutions are working somehow, and most people won't notice the difference.

In D8388#157672, @graesslin wrote:

And if there is one thing KDE is negatively famous about is that we have space shuttle control modules. Due to that we need to be careful when adding new options.

No need for two places to discuss the same thing; Let's close this in favor of https://invent.kde.org/plasma/kwin/-/issues/10, and take the discussion there.

If you want to make it official, would you be interested in helping to make tiling a part of KWin directly? https://invent.kde.org/plasma/kwin/-/issues/10
If it's bult-in then more integration could be done, for example with effects and the current quick tile system.

Please, excuse me for shameless plug, but I am currently working on a "new" tiling script extension to KWin here. I've observed, that the other tiling extensions' development was stale over the year and decided to fork one of them with the goal of making the code base more modern and new developer friendly. Also, I am aiming for the Wayland support and wanted to publish the script on the KDE Store once that's ready, but my Wayland session is not stable right now on Plasma 5.22, and I haven't found a good way to debug the script right now in the VM (I just want to see script logs for now). In the end, I really want the script to be an official KDE project and to be a part of default Plasma distribution once it's mature enough (don't want to be a perfectionist, so I am not sure where to draw a line here).

As far as tiling is concerned, there's a KWin script available: https://github.com/kwin-scripts/kwin-tiling

@ngraham It's more like the window tabs in the titlebar like we had in KDE4. From what I've seen in the video posted the KDE4 version was a lot slicker than the PopOS one. Incidentally, I'd sooo wish to see this feature come back.

Development has moved to https://invent.kde.org/plasma/kwin

(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).

Done in https://invent.kde.org/plasma/kwin/-/merge_requests/991.

I think I missed some, so next try:

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

Moved to https://invent.kde.org/plasma/kwin/-/merge_requests/611

Not a revert but rather rollback of SNI part:
https://invent.kde.org/plasma/kwin/-/merge_requests/560

We are going to revert this in favor of https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/181:
it supports all the existing functional here plus missing one (problem with short layout names was solved):

• flags and/or short text for the layouts

If any objections, please tell.

In T13927#245985, @ngraham wrote:

Ah ok, so you're asking for better tiling support to be built in.

In T13927#245985, @ngraham wrote:

Ah ok, so you're asking for better tiling support to be built in.

In T13927#245985, @ngraham wrote:

Ah ok, so you're asking for better tiling support to be built in.

For reference xdg-session-management protocol is the work-in-progress replacement for XSMP in Wayland: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18

In T13582#244856, @ngraham wrote:

Third party apps don't need to support Activities or anything Plasma-specific at all but just XSMP (X Session Management Protocol),

Gotcha. That's pretty clever.

Unfortunately the point still stands since tons of apps sadly don't support it. It's not just Firefox; Thunderbird, LibreOffice, and all Electron apps also don't seem to support it. I'm sure there are more too.

Third party apps don't need to support Activities or anything Plasma-specific at all but just XSMP (X Session Management Protocol),

pong

In T13582#244491, @ngraham wrote:

Wow. Impressive.

This kind of leads me to what I consider the Achilles heel of activities: every individual app needs to be made activity-aware. That seems hard enough for KDE software over which we have total control, due to disagreements about the scope of what set of the app's settings should be activity-aware. But since 3rd-party apps don't support activities at all, the concept just breaks down if you want or need to use 3rd-party apps. :( 5 out of 11 of my pinned apps are non-KDE apps.

This kind of leads me to what I consider the Achilles heel of activities: every individual app needs to be made activity-aware. That seems hard enough for KDE software over which we have total control, due to disagreements about the scope of what set of the app's settings should be activity-aware. But since 3rd-party apps don't support activities at all, the concept just breaks down if you want or need to use 3rd-party apps. :( 5 out of 11 of my pinned apps are non-KDE apps.

In T13582#244379, @ngraham wrote:

@alex-l You said:

I have a Firefox profile on each Activity with different favourites, history etc.

How did you do that? Does it let you have different sets of tabs per activity too?

Personally I've had the same experience as Noah: I find it easier to manage my workspace with just the task manager and Alt+Tab and whenever I try out Activities or Virtual Desktops, I don't stick with them. This goes for other platforms too which also implement these features, FWIW.

It's not that Virtual Desktops and Activities are not useful but they are just presented in a way that doesn't make obvious how to use them. I wrote some blog posts in Planet KDE years ago explaining (creative) way to use Activities. But in fact if you need to explain intended workflows with blog posts you have a UI/UX problem.

Kind of a shame that this extensive write-up has sat around for 2 months with no comments, but unfortunately, I don't have much to add. I don't really use virtual desktops or activities much and haven't seen a great need to, so it's hard for me to really see how they should work. I have tried them and they have been somewhat useful, but I never really stick with them. It's just easier for me to control everything with the task manager. I'm not saying your reasons for liking Virtual Desktops aren't valid, but perhaps one of the reasons why nothing moved forward is that a lot of people don't understand them, including KDE developers and designers like myself?

The patch is now at https://invent.kde.org/plasma/kwin/-/merge_requests/325 btw

A potential idea for fixing: allowing clients to request that the decoration be composited over their area. KWin/the KDecoration would be responsible for drawing the foreground, and the client would be responsible for drawing the background.