Announcement

Collapse
No announcement yet.

Mir Developer: Anyone Interested In Native Wayland Clients In Mir?

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

  • #41
    Originally posted by ssokolow View Post

    I stand corrected. Thanks.

    I must've read about it during one of the times when I was sleep-deprived out of my mind. That always makes a wreck out of my reading comprehension and memory.
    You're probably thinking of when Intel's management said "No! We're playing any of Canonical's political games" and gutted submitted Mir patches from their driver.

    Comment


    • #42
      A possible evolution of Mir with support for the wayland protocol and the yunit fork will both be victories for the free software! Looking forward to a unity ubuntu spin that will maybe make mr. Shuttleworth eat his words.

      Comment


      • #43
        Originally posted by Pajn View Post
        Also KWin is not designed for such use, it's just that you can do it instead which is a whole lot different than both LibWayland, Mir and QTWayland.
        Yes, KWin most certainly is "designed for such use". One of the primary goals of the KF5 port of KWin was to decouple it from Plasma so it could be used as by other DEs. They spent years refactoring KWin to make this possible, working closely with lxqt devs to make sure it was suitable for third-party sue.

        On the other hand, one of the explicit reasons Canonical gave for wanting Mir is so Mir could be designed for the specific goals of Unity without having to satisfy every DE like Wayland has to. It has been designed and built in lockstep with Unity. Miral was only announced a couple months ago and still lacks even basic features needed for it to be used by other DEs. It is not being used by any third-party DE.

        Edit: A Mir developer just confirmed this:

        Because the work has been funded by Canonical features that were important to Ubuntu Phone and Unity8 desktop have progressed faster and are more complete than others.
        Last edited by TheBlackCat; 12 April 2017, 09:44 AM.

        Comment


        • #44
          Originally posted by TheBlackCat View Post
          Yes, KWin most certainly is "designed for such use". One of the primary goals of the KF5 port of KWin was to decouple it from Plasma so it could be used as by other DEs. They spent years refactoring KWin to make this possible, working closely with lxqt devs to make sure it was suitable for third-party sue.
          You're not quite right here. On X11 there's no big deal, but as a Wayland compositor, KWin has a special plasma shell protocol extension for items like docks to be able to use, and that's what makes the Plasma desktop work there. Lxqt's panel (and other shell components) would have to be ported to use that protocol extension if it's suitable for their use, or add additional protocol to KWin to accommodate their desktop.

          Comment


          • #45
            Originally posted by BwackNinja View Post

            You're not quite right here. On X11 there's no big deal, but as a Wayland compositor, KWin has a special plasma shell protocol extension for items like docks to be able to use, and that's what makes the Plasma desktop work there. Lxqt's panel (and other shell components) would have to be ported to use that protocol extension if it's suitable for their use, or add additional protocol to KWin to accommodate their desktop.
            But KWin's panel extension isn't specific to the Plasma panel, in fact it was specifically designed not to be. Right now it is also used by things under Wayland such as krunner (KDE's popup search interface) and the plasma widget explorer.

            Lxqt would have to be ported to use some Wayland panel extension no matter what, so this isn't an issue of KWin being plasma-specific, it is an issue of lxqt not being very far along in their Wayland porting. When lxqt devs get to the panel in their Wayland port, I am sure that if there are specific needs not met by the panel extension that it doesn't currently provide those will be added, just as KWin devs have been doing with lxqt needs all along.

            But overall, the KWin panel extension was designed to be flexible and to provide capabilities outside of those needed by the plasma panel itself.

            Comment


            • #46
              Mir already achieved the purpose of speeding up the development of Wayland.

              Comment


              • #47
                Maybe if they delete MIR, and then rewrite the whole thing as a Wayland compositor then it will be relevant...

                Comment


                • #48
                  Originally posted by edoantonioco View Post
                  Mir already achieved the purpose of speeding up the development of Wayland.
                  Please provide some for this evidence. I have seen lots of people claim this but not one has actually been able to provide anything to back it up.

                  I have checked the number of commits and number of contributors to Wayland, Weston, KWin, and Mutter and none had any indication of increasing after Mir was announced.

                  Comment


                  • #49
                    Originally posted by BwackNinja View Post
                    We're talking about Mir literally becoming a Wayland compositor as well here. That is concentrating effort into Wayland, unless you think that having Mutter and KWin running as Wayland compositors is similarly a waste of effort.
                    So why is it talking about "adding support for Wayland clients", and not "making Mir a Wayland compositor"? I don't think anyone has issues with the latter.

                    Comment


                    • #50
                      Originally posted by Pajn View Post
                      There isn't that much competition really. Mutter and Kwin is both pretty specific to their own desktop environments so if you want yo write your own DE you pretty much have the choice libeweston and qtwayland. qtwayland is till far from usable for a full desktop though so it's only libweston that it's interesting to compare against.
                      Uh. KWin uses QtWayland. They made an extension to it, called KWayland (which is a generic framework, not KWin-specific), but it's still based on QtWayland.

                      Comment

                      Working...
                      X