KWinFT Going Through Code Refactoring, Working On WLROOTS-Based Usage

[polarathene]

Surprisingly, I think the best part of his work is the wrapland, disman, and kscreen projects. They completely fixed multi monitor configuration stickyness, as in when you take your laptop from one setup to the next, it remembers the screens properly. For some reason KDisplay is inconsistent with this feature and overall requires me to reconfigure my displays every other boot.

But for both systems I use wrapland, disman, and kscreen in-place of kdisplay since they remember my monitor configurations correctly.

Going to take a guess that you mixed these two up? kdisplay is the one from KWinFT project, not kscreen which is older.

I found the compositor works very well with nvidia GPUs

I assume that's on X11 not Wayland?

[oiaohm]

Yeah, I think it was with Firefox / Wayland (not XWayland, real Wayland mode). But I'd need some more tests to verify.

Wayland and XWayland versions of firefox on Linux both use GTK library for the clipboard. There was a issue with GTK applications including firefox having clipboard issues with wayland due to defective gtk library.

https://gitlab.gnome.org/GNOME/gtk/-/issues/3367

This is a horrible little mess. There have been bugs found in firefox own internal clipboard handling code that have been fixed as well that causes random failures under X11 but had been happening way more often with Wayland version as well.

There also bugs open against sway and mutter as well. Yes the reference weston compositor did not show all the faults that cause the same problem with the clipboard here.

I would call this a teething problem all around the failure points are following.
1 defective handling of clipboard in application code(this is not only restricted to firefox). Yes the defective handling also results in random cases where the clipboard fails under X11 at roughly 1 in 10000 hours of use but due to the difference wayland causing different code flow path this comes back to 1 in 24 hours of usage. So it a case bug was always there just the change to wayland makes it more visible.
2 defective handling a wrapper library this case gtk. Yes some of this is the same bad logic as the applications so X11 issue way less frequent and some of this is doing non standard stuff.
3 compositors not being 100 percent compatible with the reference for clipboard handling. There are fixes in mutter and wlroots to fix this.

Of course with such a broad set of failure points being sure they are all fixed it will take a while. There are many issues open about it that developers are looking at.

[leo_sk]

one of the most intriguing project of the year for me, personally... i'm really looking forward for this project. wlroots is a wise choice and the next wise choice would be making kwinFT a drop in replacement for kwin, and also maybe coming up with a new nice name...
thanks to the authors and keep up the good work!!!!

It is already a drop in replacement for kwin. I have been switching back and forth between kwin and kwinFT in manjaro to test it out. Its easy since kwinft is also in the repositories

[smartalgorithm]

I just updated the packages to 5.22. Have not testet them myself yet, though.

that's nice, thank!
one day i also should sit down and learn how to use that OBS...

[AHOY]

Roadmap? What's missing?

Promising project. Needs more developers though, issue reports would probably explode in numbers if this was used as a daily driver by more people. 90% of that being NVIDIA users and the usual wrong packaging/compiling from manjaro and arch users. Or configuration clashes with KWin.

[seijikun]

smartalgorithm [...] but there are binary packages available - albeit not the latest - on a community repo for openSUSE) [...].

I just updated the packages to 5.22. Have not testet them myself yet, though.

[damentz]

I definitely want to add that Roman's KwinFT fork and friends have made my experience on KDE much better. Surprisingly, I think the best part of his work is the wrapland, disman, and kscreen projects. They completely fixed multi monitor configuration stickyness, as in when you take your laptop from one setup to the next, it remembers the screens properly. For some reason KDisplay is inconsistent with this feature and overall requires me to reconfigure my displays every other boot.

As for KwinFT itself, I found the compositor works very well with nvidia GPUs, but the performance suffers on integrated graphics. So for my desktop I use `kwinft` and for my laptop(s) I use `kwin`. But for both systems I use wrapland, disman, and kscreen in-place of kdisplay since they remember my monitor configurations correctly.

[smartalgorithm]

smartalgorithm KWinFT actually is already a drop-in replacement for KWin (you'd need disman and kdisplay, too) which means you can try it out yourself in its current state (the best supported way is on Arch or Arch-derivatives, but there are binary packages available - albeit not the latest - on a community repo for openSUSE). My only request at this point would be to bring it to more distributions, particularly Ubuntu/Debian is missing a PPA last time I checked. At this point I don't think it is likely that it will ever get back-merged into upstream KDE, but as long as users can opt-in into a PPA/custom repo and as there are no conflicts with the rest of Plasma, I'd say with more popularity KwinFT could become the default compositor in the long run.

Congrats to Roman for his work, even on X11 and in its current state it is a huge improvement in my eyes to vanilla KWin.

yes, it is correct... for now... as i was addressing concerns that this cannot be hold true in the future (because of further separation in developments)

[shmerl]

I don't use wayland, but maybe this happens with GTK apps? I heard that GTK implements non-standard protocol and only one of recent releases got standard protocol implementation, but I'm not sure.

Yeah, I think it was with Firefox / Wayland (not XWayland, real Wayland mode). But I'd need some more tests to verify.

[iskra32]

Maybe one day we'll have a single extendable window manager/server for Wayland akin to Xorg but that shouldn't distract Wayland lovers from its greatness and the fact that each DE for Wayland has to reinvent the wheel and reimplement a ton of features just to allow for common features found in Xorg by default. Cue for a ton of errors, corner cases, etc. each Wayland compositor has to tackle and resolve. Anyways, disregard this message as I'm an idiot who just doesn't understand Wayland and the absolute beauty of it.

There's no technical reason why there can't be a single Wayland compositor architecture, but there isn't for good reason. In the X era, everyone and their dog would break the spec anyway causing a lot of issues with some programs. With Wayland, DEs and UI toolkits can easily negotiate capabilities and modes of operation. If you think that there is some missing feature in Wayland, propose a protocol extension for the job. This has been done before, namely by KDE with their server_decoration_manager extension. I don't like saying "write it yourself" but it's justified in this case given you seem to hate a bone-simple *EXTENSIBLE* protocol without actually suggesting anything constructive. Your hatred of Wayland is like hating HTTP because your favorite website is down.