## Using Toshy with Wlroots-Based Wayland Compositors

As noted briefly in the list of supported environments, there is now some preliminary support for certain Wayland compositors that are based on `wlroots`, with a number of caveats.  

First, the compositor must have implemented a relatively recent protocol that provides access to a list of "toplevel" window object handles, their `app_id` (application class) and `title` (window name) values, and also provides "state" information. That makes it possible to tell which window is the currently focused/active window. This is what the keymapper needs in order to apply app-specific modmaps and keymaps. You only get a fraction of the full Toshy experience without the app-specific remaps functioning.  

The necessary protocol is `zwlr_foreign_toplevel_manager_v1`. Wayland compositors like `sway` and Hyprland are known to support the protocol, but they already have other working methods for window context. So while those environments would work if you used the config override to declare `wlroots` as your desktop environment, there would be no benefit that I know of. Which other compositors based on `wlroots` might support this protocol is not known at this time. But I'll start a list at the bottom.  

To try the `wlroots` window context method with your Wayland compositor, first check to see if the protocol is supported, by running this simple test script:  

```
source toshy-venv
~/.config/toshy/wlroots-dev/check_for_toplevel_protocol.py
```

This should show all Wayland protocols implemented in your compositor, and show a message at the end about whether the `zwlr_foreign_toplevel_manager_v1` protocol is supported. 

Another script to try is:  

```
source toshy-venv
~/.config/toshy/wlroots-dev/query_topl_mgmt_protocol.py
```

This should bind to the protocol if it's available, and start showing the active window's application class and window title, and update the terminal output every time you switch to a different window, or when the title of the window changes (tabbed UIs change the title frequently). You can quit the script with `Ctrl+C`.  

If it turns out this works, you can modify a new variable in the editable "slice" in the config file tagged with `env_overrides`. 

The config file is located here (and you can open the folder easily from the tray icon menu):  

```
~/.config/toshy/toshy_config.py
```

Look for the marked slice, with the `env_overrides` tag. New installs of Toshy will have a `wlroots_compositors` variable already in place, older installs will need the variable added manually to look like this:  

```py
###################################################################################################
###  SLICE_MARK_START: env_overrides  ###  EDITS OUTSIDE THESE MARKS WILL BE LOST ON UPGRADE

# MANUALLY set any environment information if the auto-identification isn't working:
OVERRIDE_DISTRO_ID              = None
OVERRIDE_DISTRO_VER             = None
OVERRIDE_VARIANT_ID             = None
OVERRIDE_SESSION_TYPE           = None
OVERRIDE_DESKTOP_ENV            = None
OVERRIDE_DE_MAJ_VER             = None

wlroots_compositors             = [
    # Comma-separated list of Wayland desktop environments or window managers
    # that should try to use the 'wlroots' window context provider. Use the 
    # 'DESKTOP_ENV' name that appears when running `toshy-env`. 
    # 'obscurewm',
    # 'unknownwm',

]


###  SLICE_MARK_END: env_overrides  ###  EDITS OUTSIDE THESE MARKS WILL BE LOST ON UPGRADE
###################################################################################################
```

As can be seen in the comments, add your compositor's name (as identified by `toshy-env`) to the `wlroots_compositors` list. This will cause the keymapper to try to use the `wlroots` window context method, once you save the config file and restart Toshy. As user reports come in, I'll add those that can be identified and confirmed to work into the keymapper provider class, so they will work without needing to be added to the list.  

The companion D-Bus service should be running in the environment, if it's compatible. 

If you are able to get this `wlroots` method to work with any Wayland compositor besides those listed down below, open an issue and let me know which compositor it was, and the version.  

## Special Case: Pop!_OS COSMIC

An almost identical window context method works with the new Pop!_OS COSMIC desktop environment, but required some different protocol specification files and different naming internally. The setup for this has now been automated, similar to the KDE Plasma context service that automatically runs when you're in Plasma. Toshy should work with COSMIC without any manual intervention. 

## List of Wayland compositors known to work with this method

- Hyprland
- Niri
- Qtile
- sway