Posted on by Martin Flöser

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.

31 Replies to “KWin is no more”

      1. 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…

        Btw, learning from “Michael” to choose titles? 🙂

  2. 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. I like this idea, I don’t think the average user will be aware of which environment he is running

    2. If it was that simple, I’m sure they would’ve done it… But I forgot – all Open Source Devs do is to make their users life harder…

      1. Why, because the binary is getting 4 more letters? How is renaming kwin to kwin_x11 making the lives of users harder? I don’t quite get the logic.

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

            1. “KWin gets started by ksmserver”

              Not everyone who uses KWin also wants to use the whole KDE Plasma desktop.
              For example, putting the following into ~/.xinitrc gives you minimalistic but still very usable desktop:

              krunner &
              exec kwin

              Also, some users of other big desktop environments replace the respective “default” window manager with KWin, by putting “kwin –replace” in some start-up script.

              All of this works right now. Are you saying it is not supported and we shouldn’t do that?

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

              2. If a user’s writing a custom .xinitrc file, odds are they can probaby handle a filename change.

      1. Assume he means well!

        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.

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

      1. I’m not sure whether distros will create symlinks. One of the ideas is to make KWin/4 and KWin/5 co-installable. Thus they might not want to have it called kwin at all.

    6. May I ask you two things:
      1. what’s the use case of having KWin’s binary name in a script?
      2. which users start KWin that often that it’s breaking their habit?

      Don’t you think that this change might be most difficult for myself? I’m probably the person in the world which restarts kwin most often per day.

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

Comments are closed.