Document SwayWM functionality and usability

[AkechiShiro]

Hi,

SwayWM is not shown in the platform working or not, also if it is necessary to use SwayFX or not.

Thanks for the project !

[rolfmorel]

To hijack this question: which other Linux window manager/compositors will there be support for?

On 1.0.0, for both i3wm on XOrg and qtile - a WLRoots Wayland compositor - I am getting the message:

Running on Linux (undefined on tty).
This is an unsupported combination! Kando will not work here :(
Loading settings from /home/$USER/.config/kando/config.json
Loading settings from /home/$USER/.config/kando/menus.json
Kando failed to start: No backend found.

Regarding X11 support, is this supposed to be window manager/desktop environment dependent?

As for Wayland support, I see there is a backend for hyprland extending the WLroots backend. I take it the hyprland backend is necessary as the information that you need, e.g. cursor location, is not available as part of an existing (widely supported) protocol.

Regarding the above, my suggestion would be to not hardcode calling hyprctl: https://github.com/kando-menu/kando/blob/main/src/main/backends/linux/hyprland/backend.ts#L105 Instead what you could do is extend the WLRoots backend to call a helper script, e.g. kando-wlroots-info. In the first instance, this would be just a wrapper around hyprctl - in matter of fact, it would be the only place containing anything hyprland specific. With such a script in place, it would be very easy for users to replace the calls to hyprctl with calls to whatever allows for extracting the same information from their setup. When users adjust kando-wlroots-info, they'll just need to make sure they keep to the existing output format - that's all.

If implemented this way, it would be much easier for users like myself to contribute support for less common Wayland compositors back to the project.

Let me know what you think, @Schneegans!

[rolfmorel]

Alternatively, you could say that for all Wayland compositors you need something to implement the DBus interface that you have for GNOME support: https://github.com/kando-menu/gnome-shell-integration/blob/main/extension.js

So instead of kando-wlroots-info you would instead have a script like kando-wayland-dbus-helper that starts with kando and makes sure a sort of service runs that implements the DBus interface. This script would detect the running compositor and do the right thing accordingly. For users, it should be easy to adjust this script to make it compatible with their environments.

[Schneegans]

Hi there! This is quite a lot of questions, suggestions, and information for a single issue! Let's try to break it down:

X11

The X11 backend should work on almost all X11-based DEs. There can be some special cases (like on KDE), but this should be rare. Kando uses the environment variables XDG_CURRENT_DESKTOP and XDG_SESSION_TYPE to determine the current environment. "Running on Linux (undefined on tty)." indicates that both are not set properly. Try setting XDG_SESSION_TYPE=x11 before launching Kando!

Wayland

Indeed, there are not enough widely used protocols to implement this in a compositor-independent manner. As you have seen, we have custom backends for GNOME, KDE, and Hyprland. The partial wlroots backend supports simulating mouse and keyboard input, but lacks the functionality for binding shortcuts, getting the pointer location, and getting the name of the currently focused application window.

My current approach is that we need to create further backends for other compositors we want to support. If the compositor is wlroots-based, we can derive the new backend from the partial wlroots-backend.

I still think that this is the best approach:

@rolfmorel, you first suggested to add a script which is called by the wlroots-backend to retrieve the missing information. While this could work for the pointer location and the window name, it will be very hard for binding shortcuts. How should the script call a callback in Kando when the global shortcut is pressed? For Hyprland, I use their custom wayland protocol in C++. This will be close to impossible in a simple script.

Your second idea - using "something" which runs alongside Kando providing the required functionality over DBus - could work in theory, but I do not see how it improves the current situation. Functionality-wise it is very similar to what we have currently: When Kando is started, a backend is chosen based on the compositor and it runs alongside Kando and provides the functionality. However, with the current architecture we have the advantage that we can easily reuse code and derive custom backends which only change small parts of another backend.

And have you checked the native C++ source code of the wlroots backend? I think you cannot expect a user to write something like this into some sort of script language just to get Kando running. I mean, if you are capable of writing such functionality in a script, it should be easy for you to write a custom backend for Kando as well :smile:

Back to Sway

I simply have not looked into this. If sway can somehow provide the above information (getting the pointer location, and getting the name of the currently focused application window) to a client application, we could create a backend for this. Binding global shortcuts would be necessary as well, but Kando provides the --menu command-line option to open specific menus, so we could maybe also allow for backends not to support shortcuts at all...

[AkechiShiro]

@emersion regarding SwayVM could you let us know if that's possible ?

Sorry for pinging you but I see you're a regular contributor on Sway for awhile, if you're willing to help, feel free to do so, thanks !