KWinFT 5.21 Beta Pushes a "Monumental Rewrite" Of The Windowing Logic

[You-]

Shading, not shadows

oops. thanks for the correction

[bug77]

Is this branch / fork kept in sync with one that KDE Plasma 5.21 is based on so that it could be easily merged back in one day ?

Absolutely. Major rewrites are always a breeze to merge back

In other news, when my heart starts blossoming, I don't think I'm going to be in a good shape. Like, at all.

[ssokolow]

I don't know how useful of a feature that'd be to people usually? It basically just resizes your window vertically into the height of the titlebar to minimize but keep it around, then restore the original vertical height when desired. Most people probably just minimize normally or manually resize temporarily?

I use it as a way to consult what's underneath a maximized or tiled window, or interact with windows below which won't cover the titlebar entirely if raised, because it means I don't have to futz around with my titlebar to get the window back afterward, or use middle-click "send to back" on every other window, which is much more time consuming and could also mess up the stacking order if I screw it up.

[shmerl]

I had some issues with KWinFT 5.20 Wayland

How exactly do you enable kwinft? Can it be put somewhere in $HOME/.local/bin and picked up instead of system Kwin when Plasma session starts?

[polarathene]

I use it as a way to consult what's underneath a maximized or tiled window, or interact with windows below which won't cover the titlebar entirely if raised, because it means I don't have to futz around with my titlebar to get the window back afterward, or use middle-click "send to back" on every other window, which is much more time consuming and could also mess up the stacking order if I screw it up.

If you have a lot of windows isn't it better to utilize virtual desktops or overview windows with "Present Windows" effect and such? I think there's better ways to peek through the window stack for UX than temporary using the shade feature.

How many windows are we talking about here? With browser windows I can easily have 20 or so on a two display system, usually the thumbs in "Present Windows" is sufficient. If I need to interact with a window behind the active one, I just pull it out of the way and do the interaction, then I can return via mouse or shortcut. If the windows aren't the same program, you can also pretty easily switch via a few keyboard shortcuts, on that is nice for lots of windows is typing to filter windows in "Present Windows" or KRunner alt+space.

[Charlie68]

I'm happy there is this alternative project, Kwin (official) also had a major rewrite for 5.21. Users will also have more options ... Who knows maybe one day this project will be the default, but one thing is to work on a new project that has no deadlines, another is to maintain a windows manager-compositor that must be shipped and must work for any user-hardware. It goes without saying that this is not just any software, but it is a fundamental piece of the system.

[mikus]

Hopefully he has more than one monitor (preferably 4k), and feels the pain of, like everyone that has more than one display and the typical dysfunctional nature of kwin with it. Performance is still abysmal with 3x 4k displays here in standard kwin, I've thought to try this as my only option is to disable compositing after roughly a day of use.

[smartalgorithm]

Yeah... If this continues this way, soon they'll need to back-port the new features from KWin to KWinFT and not vice versa, haha. I also like how KWinFT gets rid of unnecessary QT usage (I love Qt, but also what's happening in KWinFT makes a lot of sense in that regard, Qt should be used where it makes most sense).
All is good, but I also feel how the separation is going to continue (both technically and, what's the worst, sociologically) which in turn gonna bring a very hard dilemma for the users. I hope that common sense, friendship, and love will prevail and will bring us the best solution possible.
With best regards and big hope.

[polarathene]

It seems that KWinFT does track upstream KWin and adds improvements/patches when relevant? The link also shows a sizable list of patches that were dismissed, I didn't look through them much, but assume that's because they're not applicable due the rewrite/refactoring efforts going on with both KWin and KWinFT atm.

The render refactor as Roman's next focus looks really interesting! I know KWin upstream recently got some of the features like supporting multiple refresh rates on Wayland, but KWinFT choosing to leverage wlroots is really nice to see being considered. At this rate, KWinFT is going to diverge from KWin upstream enough that it becomes an alternative Plasma compositor (or generic wayland compositor that has better integration/compatibility with Plasma?).

It'd be good to see the development get to a point that it's a solid replacement for KWin upstream and gets adopted as the default for Plasma 6.x, but even if it did make sense to do... I get the impression KDE may not be as welcoming to adopt KWinFT with their differences in opinions that led to the forking/divide anyway?

[Zan Lynx]

Hopefully he has more than one monitor (preferably 4k), and feels the pain of, like everyone that has more than one display and the typical dysfunctional nature of kwin with it. Performance is still abysmal with 3x 4k displays here in standard kwin, I've thought to try this as my only option is to disable compositing after roughly a day of use.

3x 4K is quite demanding. I managed to do that with Intel graphics a while ago and Windows slowed to about 25 frames per second on the desktop.

You've got each frame buffer, a second draw buffer backing it up, and each window is a texture also. So that's a lot of video RAM and during the composite step the background and each window is copied into the draw buffer. Then that's flipped to the output frame and scanned out to each HDMI or DisplayPort. So that's also a lot of video RAM bandwidth. Or in the case of iGPU, system RAM bandwidth.

You ought to be in pretty good shape with at least a 4 GB discrete GPU.

Now, I don't know, but if Kwin manages to force texture copies over the PCIe bus then an iGPU could actually perform better than dedicated (because copies from CPU RAM to GPU VRAM don't actually happen). That takes some persistently bad graphics programming though. Which may be the case. /shrug/