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

[Steffo]

Canonical wrote Mir patches for some KDE componentry (KWin, I think) and submitted them. The KDE devs said that, as a matter of policy, they don't accept patches into upstream that are used by only one desktop on one distro. (ie. "Come back once you've got someone else to also use Mir so it's not just 'please maintain part of our proprietary platform for us'.")

They never wrote a patch for KWIN. The maintainer (Martin Grässlin) wrote only, that he wouldn't accept patches for Mir.

[Mystro256]

Since Wayland is designed to make it easy to access the protocol in alternative ways, I would think it would much easier to create a Mir compatibility library on top of the existing Wayland protocol than it would be to completely redesign the fundamental Mir architecture from the ground up to make it much more like Wayland.

Well I've personally never touched Mir's code, but I would assume if Alan, a Mir developer, thinks it could be advantageous, it maybe worth it, at least in the short term before porting Unity to Wayland, which the forks have mentioned is their goal. I'm not a Mir nor Wayland nor X developer, so I can't answer these questions, but from what I've read, separating Unity from Mir is not going to be an easy task; so from a high level, I assume there would be short term benefits.

I doubt it would be as simple as popping Unity on top of a Wayland compositor with Mir compatibility, if that's what you're driving at.

[ssokolow]

Gnome and KDE are able to run on both Xorg and Wayland, so maybe something similar would be doable with Unity aswell. It depends on how much Canonical cared about such aspect, I guess they went all in and have integrated Unity with Mir without any effort to limit Mir dependencies to certain components only.

Canonical wrote Mir patches for some KDE componentry (KWin, I think) and submitted them. The KDE devs said that, as a matter of policy, they don't accept patches into upstream that are used by only one desktop on one distro. (ie. "Come back once you've got someone else to also use Mir so it's not just 'please maintain part of our proprietary platform for us'.")

[TheBlackCat]

Well I assume it would be useful in the short term, allowing Wayland clients to run with Unity 8 (or rather one of the forks). AFAIK migrating Unity 8's code to Wayland is no easy task (likely requiring large reworking of code if I understand correctly).

Since Wayland is designed to make it easy to access the protocol in alternative ways, I would think it would much easier to create a Mir compatibility library on top of the existing Wayland protocol than it would be to completely redesign the fundamental Mir architecture from the ground up to make it much more like Wayland.

[TheBlackCat]

I wouldn't draw the conclusion that Wayland has better architecture based on that statement, but rather it would be easier for developers to maintain only a single code path.

There are two paragraphs. The first talks about the Wayland architecture being better, the second talks about maintaining two code paths being difficult.

[curfew]

Well I assume it would be useful in the short term, allowing Wayland clients to run with Unity 8 (or rather one of the forks). AFAIK migrating Unity 8's code to Wayland is no easy task (likely requiring large reworking of code if I understand correctly).

Gnome and KDE are able to run on both Xorg and Wayland, so maybe something similar would be doable with Unity aswell. It depends on how much Canonical cared about such aspect, I guess they went all in and have integrated Unity with Mir without any effort to limit Mir dependencies to certain components only.

[Mystro256]

Reading the blog post again, I noticed these statements:

...

So, in other words, Wayland has a better architecture, and having to support Mir creates an unnecessary burden for third-party developers. This are exactly what critics of Mir have been saying since day 1, but that Mir developers have consistently denied. So it is nice to see Mir developers finally admit these issues were real.

I wouldn't draw the conclusion that Wayland has better architecture based on that statement, but rather it would be easier for developers to maintain only a single code path.

[sp82]

Please let's Mir and X die. Concentrate the effort into Wayland.

[Mystro256]

It isn't a question of why they shouldn't do this, it is a question of why they should. That is the key thing missing from the blog post: solid technical reasons why anyone would want to use Mir in this way rather than just having a conventional Wayland compositor.

This has been a consistent problem with Mir from day 1, they haven't been able to provide technical, factually-correct reasons why anyone should want to use Mir to begin with.

Well I assume it would be useful in the short term, allowing Wayland clients to run with Unity 8 (or rather one of the forks). AFAIK migrating Unity 8's code to Wayland is no easy task (likely requiring large reworking of code if I understand correctly).

[TheBlackCat]

Reading the blog post again, I noticed these statements:

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.

For the wider community native support for Wayland clients in Mir would make the task of toolkit maintainers and others simpler.

So, in other words, Wayland has a better architecture, and having to support Mir creates an unnecessary burden for third-party developers. This are exactly what critics of Mir have been saying since day 1, but that Mir developers have consistently denied. So it is nice to see Mir developers finally admit these issues were real.