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

[TheBlackCat]

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.

[BwackNinja]

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.

[TheBlackCat]

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.

[zoomblab]

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.

[Luke_Wolf]

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.

[ssokolow]

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

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.

[ldo17]

For the life of me I am at a loss to figure out how much effort could be wasted in display server development and protocols when Quartz/Quartz Extreme [Display PDF, etc] developed for as Display Postscript at NeXT [alum here] and later at Apple [alum here], but then I look back to the original development of X versus NeXT Display Postscript and NeXT WindowServer both proven to be light years ahead of MIT-X and can't imagine after nearly 33 years it has taken this long to realize your designs were failures.

It certainly has taken a long time for the X camp to realize that simplicity lies in a dumb server, with all the sophistication at the client end.

But Display PostScript (and Sun’s NEWS) was part of that mistake, too.

[Slartifartblast]

This is one of those instances where less is more, RIP Mir.

[littleowl]

No, Mir is designed to support multiple DEs. Even MirAL does support multiple kinds of environments, for example tiling which Unity does not use.

The last Mir release, I spent some time on, was ~0.19 and I had feeling the design decisions are pretty Unity centric. Anyway, I am not afraid that we will not have enough of Wayland compositors. I would bet more on Weston which *is* a reference and has support of various SoC manufactures.

[cb88]

The best option is to throw Mir under the bus.... and extend libweston untill it does all you need and either use libweston-desktop or implement your own compositor as a thin layer on top of libweston.

Then everyone benefits... that is the entire point. Deleting cruft is a good thing... and at this junction Mir is pure cruft.