Support Wlroots protocols

[hcsubser]

There are protocols created by the wlroots project that are supported by most of current usable Wayland compositors(compositors like Sway, Wayfire, labwc,river and even some protocols are supported by Kwin).

Why would a support for this protocols be good?
For example best thing is interoperability it would allow a panel that was written for sway also to run on Wayfire or Maui-shell if it implements support for these protocols in the compositor.
There are a lot of X.Org specifig tools that do not work on wayland but have their respective alternatives that work with wlroots protocols(xtype,xrandr,scrot,xbacklight -> wtype,wlr-randr,grim,light, to name a few). Here is a list of all these alternatives on Sway wiki.

I and many others frequently use these X11 specific tools for scripts for example and would love to use their counterparts on wayland with maui-shell.

It would be nice, in the long run, for maui-shell panels and docks to use wlroots protocols like wlr-layer-shell(which is supported by all comopositors even KWin, except Gnome) and wlr-foreign-toplevel-control so that those components can also be used on other wayland compositors.

This is not something that can be achieved that easily but would really benefit the project in the long run, (especially since wlroots are trying to upstream these protocols and it would be nice to have support for them)

Liri shell is also I believe built on top of qtwayland and they already support most of wlroots protocols therefore that project could be a good reference point.

[hcsubser]

here is also a list of programs that use wlroots protocols(stuff like panels, docks, brightness controlers,different tools...),all of those could work on maui-shell if required protocols get implemented.

https://github.com/solarkraft/awesome-wlroots

[milohr]

That's the plan

[luka177]

It is questionable plan, as maui is QT stuff current qt compositer is better option then wlroots, or other option is kwin.

[philmmanjaro]

Well there is also KwinFT ...

[subdiff]

Thanks for mentioning KWinFT. In fact KWinFT could be an interesting option for Maui Shell to consider making use of for its window management part.

We're currently working on splitting off reusable libraries what will be hopefully done till mid this year. But early development versions should be available earlier to work on. With such a system Maui Shell could decide on its own what KWinFT components it wants to make use of up to the point of providing a complete compositor experience similar to KWin/KWinFT itself or, what I would recommend considering the strategic goals of Maui Shell, with a subset of features for example excluding advanced things like window rules.

The declared goal of KWinFT is to be independent of any specific desktop, allowing independent projects to make use of the provided components. So we're actually keen on providing integration and support for a like Maui Shell.

And of course since this ticket mentions wlroots: KWinFT is working together with the developers of wlroots, actively integrating wlroots in its code base and we want to support wlroots protocols whenever possible instead of building separate ones.

[barolo]

When going with KWin please check before its power usage (when idle) on a tablet or something like that, and compare it to other modern Wayland compositors like Sway. Recently they had a bad streak (which is still ongoing) of mouse cursor blasting either CPU or GPU with each movement and draining devices quickly.

[barolo]

And please please don't make it dependant on Kwin, Maui Shell would be great with simpler Wayland compositors as mentioned in initial post.