Announcement

Collapse
No announcement yet.

KWinFT 5.24 Released - Continues To Advance Its Wayland Support, Expand On Wlroots

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by bug77 View Post

    That sounds better, yes. The only reason for retrofitting that I can think of, is keeping code similar for maintenance purposes. But that's just me guessing.
    Exactly that's one of the main reasons. Another is that we need most of the X11 logic anyway for Xwayland. So cleaning the X11 code up helps us in most cases on Xwayland too. And one other reason is that by cleanly abstracting over the two windowing systems X11 and Wayland we are theoretically ready to drop in support for another one. Now that sounds far-fetched, but as there are actually some early plans for Wayland 2.0 being made which won't offer backwards compatibility, this could actually be needed at some point.

    Comment


    • #52
      If this software is useful and full-ready, it could be adapted for pure Wayland purpose in order to divide PLASMA based on X11 and PLASMA based on Wayland, so to avoid the XWayland necessity. The reason to have two different graphical stacks is to reduce the complexity on the management of the Os software alongside the possibility to offer two different solutions to the end users based on hardware specs.
      It's apparent at this specific context of development evolution, how many users take benefits from Wayland unlike other users because of hardware conformance issues. Moreover, some users also prefer the one to the other one just only for subjective convictions. Simplification and flexibility are the way to go in my modest opinion. If this step was realizable, KDe PLASMA could be the first major graphical solution based on pure Wayland.
      Last edited by Azrael5; 11 February 2022, 09:03 AM.

      Comment


      • #53
        I don't understand why this has to be a KDE only problem, Mutter also supports both Xorg and Wayland. However if I were to start developing a composer I would do it for wayland, it makes no sense today to support in a new Xorg compositor. The user who replaces Kwin with KWinFT today has more problems than solutions, but this does not mean that in the future it can be different, but at the moment this is the situation. I didn't like those lines about KDE innovation either, but everyone is free to say what they want, but then don't say it's KDE's fault for these strained relationships, I've never heard a KDE dev speak, in a negative way on KWinFT, the opposite is true.

        Comment


        • #54
          Originally posted by Quackdoc View Post
          gamescope works as a standalone compositor too. I regularly use it directly from TTY for some older games windows apps. I suspect that steamos will be doing something similar
          The parties who have steamdecks in their hands don't have gamescope on them at this stage being run as a standalone compositor. Valve has been doing a lot of upstream work on KDE.

          Comment


          • #55
            Originally posted by Charlie68 View Post
            I don't understand why this has to be a KDE only problem, Mutter also supports both Xorg and Wayland. However if I were to start developing a composer I would do it for wayland, it makes no sense today to support in a new Xorg compositor. The user who replaces Kwin with KWinFT today has more problems than solutions, but this does not mean that in the future it can be different, but at the moment this is the situation. I didn't like those lines about KDE innovation either, but everyone is free to say what they want, but then don't say it's KDE's fault for these strained relationships, I've never heard a KDE dev speak, in a negative way on KWinFT, the opposite is true.
            I believe that exactly what Martin Graesslin said: KWin is an X compositor. If he was solely focused on Wayland, he'd start from scratch.
            However KWin does not have the luxury of ignoring X just yet. I, for one, a thankful that because of the open source nature of the project, alternatives ca be explored. The amount of drama around what's going on, is mostly negligible. If KWinFT proves its worth, I'm sure a way of displacing KWin will be found when the time comes. And if KWin figures things out first, well, that's that...

            Comment


            • #56
              Originally posted by bug77 View Post

              I believe that exactly what Martin Graesslin said: KWin is an X compositor. If he was solely focused on Wayland, he'd start from scratch.
              However KWin does not have the luxury of ignoring X just yet. I, for one, a thankful that because of the open source nature of the project, alternatives ca be explored. The amount of drama around what's going on, is mostly negligible. If KWinFT proves its worth, I'm sure a way of displacing KWin will be found when the time comes. And if KWin figures things out first, well, that's that...
              I agree with everything, what I don't understand is why when it comes to Mutter, nobody raises the problem?
              Mutter was developed for Xorg and then evolved to support Wayland as well, it's the exact same path that Kwin did, with different timelines. https://en.wikipedia.org/wiki/Mutter_(software)

              Comment


              • #57
                Most recent KWinFT running inside a Debian VM:


                Thank you Roman.


                The script to build KWinFT from git HEAD (download necessary dependencies, set up files, compile, ...) on a Debian system
                is being released to the Public Domain ("CC0" "No Rights Reserved") by me.

                You may copy it, modify it, do whatever you like with it.
                You may host it on your GitLab, modify it, do whatever you please with it. "You" meaning everyone interested.

                IT ALSO COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! Check it before you do something silly.

                Please read the section at the beginning of the file.
                Have fun!


                Download is here -> link


                Start by opening the session with Konsole, e.g.:
                Code:
                source ~/k/kwinft-plasma-meta/kde/plasma-desktop/build/prefix.sh
                dbus-run-session kwin_wayland --exit-with-session konsole >stdout.txt 2>stderr.txt
                and from there start plasmashell in case you can't start into the session immediately by running e.g.
                Code:
                source ~/k/kwinft-plasma-meta/kde/plasma-desktop/build/prefix.sh
                dbus-run-session startplasma-wayland 2>&1 | tee ~/my-kwinft-output
                Last edited by reba; 11 February 2022, 03:33 PM.

                Comment


                • #58
                  I think it's an interesting project. I'm sure KWin has its baggage, but the same time has been very stable for me.

                  Maybe that's the issue with innovation too, KWin has more focus on stability, which for me is a good thing.

                  Will be interesting to see the future of this, and if it will get adopted by distros as default.

                  I will try it from time to time, if just to check if I grow a fancy for it.

                  Comment


                  • #59
                    Originally posted by bug77 View Post
                    I believe that exactly what Martin Graesslin said: KWin is an X compositor. If he was solely focused on Wayland, he'd start from scratch.
                    However KWin does not have the luxury of ignoring X just yet. I, for one, a thankful that because of the open source nature of the project, alternatives ca be explored. The amount of drama around what's going on, is mostly negligible. If KWinFT proves its worth, I'm sure a way of displacing KWin will be found when the time comes. And if KWin figures things out first, well, that's that...
                    There are two different major methods here.
                    1)Ship of Theseus method https://en.wikipedia.org/wiki/Ship_of_Theseus
                    2)Rebuild new code base.

                    Both in the end result in a completely new ship. Ship of Theseus method things can get messy but you normally always have somewhat functional boat where rebuild new code base completely you have a gap without a boat.

                    Of course you have the option of doing both at the same time.

                    Originally posted by Charlie68 View Post
                    I agree with everything, what I don't understand is why when it comes to Mutter, nobody raises the problem?
                    Mutter was developed for Xorg and then evolved to support Wayland as well, it's the exact same path that Kwin did, with different timelines.
                    This is wrong different users have raise the issue that for wayland mutter should be rebuilt from scratch. Difference between KDE and Gnome is resources. The resources to fork off KWin and try something different does exist around the KDE world and has been lacking with Gnome.



                    Comment


                    • #60
                      Originally posted by oiaohm View Post
                      There are two different major methods here.
                      1)Ship of Theseus method https://en.wikipedia.org/wiki/Ship_of_Theseus
                      2)Rebuild new code base.

                      Both in the end result in a completely new ship. Ship of Theseus method things can get messy but you normally always have somewhat functional boat where rebuild new code base completely you have a gap without a boat.

                      Of course you have the option of doing both at the same time.
                      The first approach doesn't really work for software this big, especially if people that initially built the "ship" aren't still around.

                      And as I've said before, Wayland is not just newer, it has a completely different architecture (for better or worse), so supporting both X and Wayland at the same time is quite different from supporting, say, IPv4 and IPv6.

                      Comment

                      Working...
                      X