KWin is no more

Now that I have your attention: the binary of KWin/5 just got renamed from “kwin” to “kwin_x11″. For you as a user nothing changes, the startup is adjusted to start kwin_x11 instead of kwin. Nothing else changed. The D-Bus interface is still org.kde.KWin, the config file is still “kwinrc”, etc. etc. Only if you start KWin manually remember to run “kwin_x11 –replace &” instead of “kwin –replace &”.

Say thanks to Hrvoje Senjan for preparing the patches to rename the binary and adjust all the places where the binary name is used.

What’s the point of renaming it into kwin_x11 then? And in general, usually, the old version is renamed(ex: qt4) and the newer version takes it’s place(ex: qt – in this case).
I guess you guys know better why should you take the untraditional route…

A better solution would be to leave kwin binary and create two libraries libkwin_x11.so and libkwin_wayland.so.Then kwin by default would detect the environment it’s running in, and load an appropriate library. At the same time kwin –displayserver=x11 or kwin –displayserver=wayland would unconditionally try to load the x11 or wayland backends.

The current solution breaks scripts and users’ habits. But I guess it’s in the nature of Open Source to break everything all the time without thinking twice.

1) Itls less easy to find/guess. Usually, programs can be started in a terminal using the lower-case version of their name.

2) It forces users to care about the distinction between X11/wayland. E.g. you won’t be able to tell newbies to “just run `kwin –replace` to try KWin” anymore, you hav to ask them to find out more information first.

3) It forces users who are already accustomed to starting it manually, to relearn.

3) It forces users who use custom startup scripts, to change those scripts (and then change them *once again* when they move to wayland in the future).

I’m not saying that those are deal-breakers, but claiming that renaming an important binary causes no damage at all because “it’s just 4 letter more”, is simply naive.

1) not really an issue in the case of KWin. KWin is just not an application one normally starts from a terminal

2) well easy to fix. Starting kwin_x11 on Wayland: “you seem to be using Wayland, consider starting kwin_wayland instead”.

3) that goes together with 1: users dont’t (or shouldn’t) start KWin manually. If they do, they will be able to adapt quickly.

4) well I’m not sure we support custom startup scripts. KWin gets started by ksmserver and that’s the only way to do it. Now we changed a lot with the KWin4 -> KWin5 transition and a custom startup script might be broken anyway. With Wayland there will be even more to change. So that just doesn’t sound like a legit argument to me. Anyway a simple symlink fixes it.

The way to use KWin through scripts is to interact with the DBus interface and that didn’t change at all.

I’m not sure whether that works and what side effects it would have. It would result in e.g. the frameworksintegration plugin not being picked up for KWin. Whether KWin works at all without that plugin I do not know (without Qt 5.3.1 it wouldn’t). Thus such a script needs to be adjusted for KWin5 anyway.

There is no simple upgrade to KWin5 – there are many changes and I doubt that this change matters given all the other changes starting from we don’t support a configuration upgrade path.

I once asked Lennart why he didn’t did something like a symlink for network devices (eth0, etc). Apparently totally impossible. He explained the terribly obvious thing for him to me and actually he had explained it already 10 times or so.

Since that explanation I’ve explained it maybe 10 times to other people.

Distro creators will just add symlinks depending on which technology is used by default (like it was done with python2/3, for example). I think “kwin_wayland” is more a separate application already – it’s not a window manager anymore, it’s a display server now.

one could also ask the question the other way around There is a reason why I decided for kwin_x11. To use tools like kquitapp5 one is not allowed to use a hyphen. We run into this problem with plasma-shell which we had to rename to plasmashell.