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

[BwackNinja]

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.

[TheBlackCat]

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.

[BwackNinja]

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?

[TheBlackCat]

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.

[BwackNinja]

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.

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?

[GreatEmerald]

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.

[GreatEmerald]

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.

[TheBlackCat]

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.

[nomadewolf]

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

[edoantonioco]

Mir already achieved the purpose of speeding up the development of Wayland.