-
Notifications
You must be signed in to change notification settings - Fork 613
Wayland
Hopefully, yes. “Wayland support” is a quite vague notion, and it is not only to rofi to make all the work.
A pull request was opened to allow rofi to work under Wayland with Sway and some other window managers, but this PR was closed and spun off into a separate Wayland-compatible fork of rofi. If you are are interested, check out the fork and send feedback there.
A lot of the remaining content on this page is outdated.
For rofi to work on Wayland, we need a way for it to communicate its special behaviour needs. This is done via a specific Wayland protocol. One possible protocol is part of Wayland Wall.
Additionally, we need a protocol to list client surfaces, there is one for that too.
rofi supports this protocol in the wip/wayland branch.
This version is a rewrite of the backend part. This means features were removed, others got added back, but not everything works for now.
This branch is outdated. A lot of changes have happened to rofi since then, and there is no immediate plan to update the branch.
However, rofi alone supporting this protocol will have no effect. The protocol needs to be supported in the compositors too. The Wayland Wall effort tries to have compositors implementations too.
For compositors based on libweston, there are a set of plugins to support Wayland Wall protocols, specifically one for the launcher-menu protocol. There is also a bare version of the window-switcher protocol, but it doesn’t support workspaces (since it is a generic plugin).
For compositors using WLC, there is another Wall project. However, there is no easy way to hook into WLC in addition to the compositor, so direct support is needed. For Orbment, plugins are provided.
Since not every developer of WLC-based compositors are willing to support Wayland Wall protocols, there is an LD_PRELOAD injector that is usable. Use with care.
Wayland compositors can already support rofi by supporting Xwayland.
Xwayland is a special X11 server, that will forward windows to the Wayland compositor.
By supporting it, a Wayland compositor will be able to display X11 clients the same way the usual X11 server would do.
For compositors based on wlc, wlc itself takes care of this support, but it has bugs (as of 2016-08-14).
For compositors based on libweston, this support is split in three parts.
- The Xwayland server launch: has to be implemented in the compositor itself (for safe signal handling).
- The X window manager code: it is a runtime loadable module shipped with libweston that compositors have to load.
- The window management code: this is the core code of a compositor. These three parts need some glue to work together. A compositor using the helper libweston-desktop library will use the same API for Wayland and Xwayland clients.
But rofi is no regular X11 client. rofi uses the "override-redirect" X11 window property, to escape from the X window manager (and, e.g. not being tiled). This can lead to some more issues, especially on the input grabs.
And why not native Wayland support?
In a Wayland environment, clients have no control over their surface position, and they cannot grab the input. This is a feature, and most clients will deal with it perfectly, because they have no need for such things.
But rofi need that, so it cannot work out-of-the-box with Wayland. It needs a way to tell the compositor about that, and the compositor needs to understand.
As a side requirement, the protocol used to that end should not make rofi order the compositor about anything; Wayland prefers descriptive protocols.
This (hypothetical) protocol would need an implementation in rofi, and in every compositors wanting to support it. This may happen, probably not soon.
Also, big Desktop Environment (GNOME, KDE, E), will unlikely ever support it.