Announcement

Collapse
No announcement yet.

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

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

  • #51
    Originally posted by TheBlackCat View Post
    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.
    While true, we've moved away from the initial issue -- working with a library for building wayland-compatible compositors. KWin may not be plasma-specific (though the KWayland extensions in question are called the plasma shell protocol extensions) and that works for Lxqt which specifically uses KWin, but doesn't help with building a Wayland compositor like libwayland, swc, or as discussed here MirAL could do.

    In addition, MirAL is toolkit agnostic unlike qtwayland.

    Originally posted by GreatEmerald View Post
    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.
    While technically equivalent, saying "adding support for Wayland clients" doesn't imply removing or deprecating Mir protocol support like "making Mir a Wayland compositor" does. If you say "I don't think anyone has issues with the latter," then what are the issues with the former?
    Last edited by BwackNinja; 14 April 2017, 03:14 PM.

    Comment


    • #52
      Originally posted by BwackNinja View Post
      While technically equivalent, saying "adding support for Wayland clients" doesn't imply removing or deprecating Mir protocol support like "making Mir a Wayland compositor" does. If you say "I don't think anyone has issues with the latter," then what are the issues with the former?
      It didn't sound to me like they are equivalent.

      "Making Mir a Wayland compositor" doesn't imply "removing or deprecating Mir protocol support", it would be possible to support both protocols. Most Wayland compositors these days still support X11, but that doesn't make them any less of a Wayland compositor.

      On the other hand, "adding support for Wayland clients" could be to add a libwayland-client compatibility shim that translate libwayland-client library calls into MirAL library calls or Mir client library calls without actually supporting the Wayland protocol internally. Some additions to Mir would likely be needed, but not complete support for the Wayland protocol. Or they could do something like XWayland where they provide Wayland clients a personal Wayland environment running inside the Mir server (KWin supports running Wayland clients inside X11 for testing purposes).

      So I guess the main question is whether they are proposing adding full Wayland protocol support alongside Mir protocol support, or whether they are planning to just provide some sort of compatibility layer without supporting the Wayland protocol.

      Comment


      • #53
        Originally posted by TheBlackCat View Post
        So I guess the main question is whether they are proposing adding full Wayland protocol support alongside Mir protocol support, or whether they are planning to just provide some sort of compatibility layer without supporting the Wayland protocol.
        A compatibility shim was never proposed and the wording of the post excludes that as a real possibility, hence my assumptions on what you expected the differences between the two were.
        This opens up an interesting possibility: there’s no obvious technical reason that Mir could not support clients using libwayland directly. It would take some research to confirm this but I can’t foresee anything technical blocking such an approach.
        ...
        In a traditional environment where the libraries are a shared resource updates simply need to maintain ABI compatibility to work with existing clients. That makes it possible to keep Mir server and client and server libraries “in step” while making incompatible changes to the communications protocol.

        However with Snaps the client and server “snap”s package the libraries they use with the applications.That presents issues for keeping them in step. These issues are soluble but create an additional burden for Mir, server and client developers. Using a protocol based solution would ease this burden.
        There isn't much room for a shim to fit in there. Supporting the client protocol would be the goal, not a replacement libwayland-client library. Is that sufficient?

        Comment


        • #54
          Originally posted by BwackNinja View Post
          Supporting the client protocol would be the goal, not a replacement libwayland-client library.
          I don't see anything in that quote that suggests that. It talks about using libwayland, not using the wayland protocol. If he wants to adopt the wayland protocol he could just say that. Instead he talks about supporting the wayland library, and even then only for clients.

          Comment


          • #55
            Originally posted by TheBlackCat View Post
            I don't see anything in that quote that suggests that. It talks about using libwayland, not using the wayland protocol. If he wants to adopt the wayland protocol he could just say that. Instead he talks about supporting the wayland library, and even then only for clients.
            libwayland is an implementation of the protocol. Alan Griffiths talks about supporting clients that use libwayland. Keeping ABI compatibility for libraries within snaps is considered more trouble than it's worth, so "a protocol based solution would ease this burden". As such, as a snap, we're talking about /only/ Wayland compatibility within the snap, not calling libraries outside of it for these tasks -- aka libwayland inside the snap, not a modified version or replacement outside. This is to avoid ABI compatibility issues. Hence, this means supporting the protocol itself.

            Talking about a library shim way of dealing with that fails to address the issues he himself raises with the current situation of Mir.

            Comment

            Working...
            X