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

[shmerl]

Does clipboard work better with KWinFT? It's a massive mess with KWin in Plasma 5.22 in the Wayland session - totally broken and only copies things every other time.

[Yeayo guy]

Does clipboard work better with KWinFT? It's a massive mess with KWin in Plasma 5.22 in the Wayland session - totally broken and only copies things every other time.

Is not totally broken, it fails (sometimes) from Xwayland apps to Wayland apps, and yes is annoying.
Maybe in the future KDE devs and KwinFT dev could merge their work again.

[shmerl]

Is not totally broken, it fails (sometimes) from Xwayland apps to Wayland apps, and yes is annoying.
Maybe in the future KDE devs and KwinFT dev could merge their work again.

For me it fails Wayland to Wayland, not XWayland even.

[smartalgorithm]

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!!!!

[d3coder]

Does clipboard work better with KWinFT? It's a massive mess with KWin in Plasma 5.22 in the Wayland session - totally broken and only copies things every other time.

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.

[ms178]

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.

[d3coder]

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.

Agree, for example transparency works correctly. On vanilla decorations sometimes are not transparent and on KwinFT it works properly.

[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.

[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.

[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)