Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Wlroots protocols #3

Open
hcsubser opened this issue Dec 27, 2021 · 5 comments
Open

Support Wlroots protocols #3

hcsubser opened this issue Dec 27, 2021 · 5 comments
Labels
feature-request Issues to discuss future features to be added to this software.

Comments

@hcsubser
Copy link

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
Copy link
Author

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

@UriHerrera UriHerrera added the feature-request Issues to discuss future features to be added to this software. label Dec 27, 2021
@milohr
Copy link
Member

milohr commented Dec 29, 2021

That's the plan

@luka177
Copy link

luka177 commented Dec 29, 2021

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

@philmmanjaro
Copy link

Well there is also KwinFT ...

@subdiff
Copy link

subdiff commented Jan 4, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Issues to discuss future features to be added to this software.
Projects
None yet
Development

No branches or pull requests

5 participants