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

[ssokolow]

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.

Multiple monitors in general tends to not get enough testing. I'm running a 1280x1024, 1920x1080, 1280x1024 setup with compositing disabled and part of the reason for it originally was that, when it was just two 1280x1024 monitors, games had a tendency to make the assumption that "center of the desktop == center of a monitor" would be true and misbehave otherwise... for example, by achieving relative pointer motion by warping the pointer to the center of the desktop, then calculating offsets relative to the center of the fullscreen'd window.

(Compositing is disabled because I've yet to run into a compositor that can run for months at a time without bugging out, while most WMs last and last without it. At the moment, my uptime is 80 days, 8 hours, and 18 minutes.)

[ssokolow]

If you have a lot of windows isn't it better to utilize virtual desktops

That would switch all my monitors when all I want to do is do a quick temporary swap on the middle one. I'd be more likely to break out my libwnck skills from writing QuickTile and bind a global hotkey that means "send window to back and remember which one until I run you again so I can bring it back to the front by pressing a second time"... of course, that wouldn't be something I could accomplish using only the mouse, so I might have to move the hand on the keyboard when I otherwise wouldn't.

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.

Aside from my not liking the aesthetics of changing *everything* like that, it would require compositing, which makes my WMs crash-prone after a few weeks of uptime.

(When I was using compositing, I'd aggressively turn off animations aside from a sub-300ms slide transition for switching virtual desktops to give a spatial cue. I don't like my desktop wizbanging around and changing from filled with black-on-white text and browser windows to a bunch of little white squares on a dark background.)

Another problem with present windows is that it has the same problem as with the taskbar. I have to slow down to find the window I'm looking for because I may have an active set of five or six windows spread in four columns across three screens (two or three stacked in one of the columns) plus my slide-down terminal, with another 10-30 windows in my "non-active set" sitting behind the rest. With my current approach, it's just "slam cursor to top row of pixels, double-click, maybe move it down and scroll-wheel around then slam back up again, double-click a second time to return to what I'm working on".

[curfew]

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.

This is actually a point of interest for me as the KDE folks just rewrote the compositing code especially multi-display setups in mind. It should bring improved performance and also support for heterogenous refresh rates. I think this work is due for release on February 16 when Plasma 5.21 lands.

So now Kwin is supposed to have a modern compositor whilst KwinFT might be stuck with patched legacy code? And is the solution to merge the upstream work or spend lots of time rewriting something that might not need a second rewrite?

[CTown]

This is actually a point of interest for me as the KDE folks just rewrote the compositing code especially multi-display setups in mind. It should bring improved performance and also support for heterogenous refresh rates. I think this work is due for release on February 16 when Plasma 5.21 lands.

So now Kwin is supposed to have a modern compositor whilst KwinFT might be stuck with patched legacy code? And is the solution to merge the upstream work or spend lots of time rewriting something that might not need a second rewrite?

Window managers did not always have compositors (the more fancy features) but did have window management code (the core features). So, the compositing code is newer as it is tacked on the window management code. The recent Kwin update focused on the former while this KwinFT update focused on the latter in order to rebuild Kwin's very foundation. At least that was my take on the matter (and hopefully I will be corrected if I'm wrong).

Roman actually wrote he does not like the new changes to Kwin in his article under the section, Simple is Difficult

[curfew]

Window managers did not always have compositors (the more fancy features) but did have window management code (the core features). So, the compositing code is newer as it is tacked on the window management code. The recent Kwin update focused on the former while this KwinFT update focused on the latter in order to rebuild Kwin's very foundation. At least that was my take on the matter (and hopefully I will be corrected if I'm wrong).

I asked questions so which is it, yes or no?

Actually one of the early modifications to Kwin code was "rework of composition pipeline", which was mentioned already as early as the initial project announcement.

Roman actually wrote he does not like the new changes to Kwin in his article under the section, Simple is Difficult

That's not really a reference to anything. He doesn't like the way a singular developer tends to push changes in general. However, these compositor changes for Plasma 5.21 appear to be more than "lipstick on a pig".

It's a little bit funny to observe the progression of the KwinFT developer's mentality, though. In the initial project announcement he acknowledged that one of the issues with "classic" Kwin is that they are responsible for not breaking the desktop all the time, which more or less justifies their stance of avoiding massive rewrites as the primary solution to fixing things. But now he's openly ranting and even naming the Kwin developer for making (in his mind) stupid decisions.

[schmalzler]

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 double click on the title bar to shade and I use it regularly. I find it handy e.g. on dialogs, but also use it to get a quick glimpse on the window below. It's way faster than moving the dialog/window around or resizing it manually. Also it requires no context switch like having to deal with the window list/task bar plasmoids.

[R41N3R]

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?

I did install kwinft as a normal package and it replaced several Plasma packages. For testing you can probably compile and run kwinft + plasma-git probably with the usual methods but I didn't try it.

[curfew]

I use double click on the title bar to shade and I use it regularly. I find it handy e.g. on dialogs, but also use it to get a quick glimpse on the window below. It's way faster than moving the dialog/window around or resizing it manually. Also it requires no context switch like having to deal with the window list/task bar plasmoids.

I.e. it's for people who use mouse more than keyboard. I used to be a fan of shading, too, even on my Windows days (via BBLean and WindowBlinds).

Later I switched to making use of virtual desktops. Usually I run a single window per desktop. I also used to run a dual-display setup, so I could keep two large windows in my view at once. But even nowadays on a laptop with no external monitors vdesks are enough, although sometimes I do also use Alt-tab when running more than three windows.

[ktecho]

I've asked it several times, but maybe this topic is a little bit more related to it:

Have any of you managed to get two diferent screen scales with X11? I have a HiDPI display and another HD one. I know that it's not supported by Plasma, but maybe changing configuration files or something...

I tried wayland this weekend and this works, but it was very buggy. A lot of stuff didn't work. I've seen that it has improved a lot in last releases, but I'm stuck in 5.19.5 (kubuntu backports didn't release 5.20 and I don't think they'll release 5.21), so I would prefer staying X11 where everything works perfect

[bug77]

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.

Well, KDE 6 is also de-QTing where it makes sense.