Using Wayfire as the compositor for LXQt (LWQt)

[marcusbritanicus]

I'm starting this thread to discuss various ideas for using Wayfire as a compositor for LXQt. While discussing about Wayland support in LXQt (#10), we have discussed a significant amount about Wayfire. This way, we can streamline our Wayfire discussion here.

I have been Wayfire for the past two years and actively developing a Desktop shell for it. I feel that developing a plugin for Wayfire will help LXQt a lot. This approach has a few advantages (I mentioned them in the Wayland thread as well):

1. An lxqt plugin for wayfire would allow us to not only start the whole desktop, it would also give us the flexibility to simply read LXQt config files and position the desktop components just the way it's done in an X11 setup.
2. On modifying the config, the plugin would be able to apply the changes immediately - this is something that's not possible to do with window rules, or other wayfire patches.
3. No modifications would be required on either side (Wayfire or LXQt). All that would be required is to have a wayfire config file (with lxqt plugin added to the list of plugins).

Here are a few valid points raised by @stefonarch

Actually there are not many things left to sync as lxqt-session handles quite a lot already.

• Settings for keyboard (layout, layout switch, repeat and so on) mouse/touchpad speed ecc. (cursor can be already set by lxqt-config-appearance)
• issue is lxqt-globalshortcutsd, as shortcuts are handled by the compositor and therefor all apps launched by shortcuts cannot be closed gently by lxqt-session. An import of ~/ .config/lxqt/globalkeyshortcuts.conf should be selective but the GUI doesn't show anything under wayland and is useless atm.

[stefonarch]

For some months I've used all possible wayland sessions (5), now mostly wayfire (thanks to the recent patches and workarounds) and hyprland.

Probably a mix between a lxqt-plugin (or several default plugins enabled) and window rules is needed, as at least lxqt-session has to be started by wayfire and probably most users will have another wayfire session, so the configurations should be seperated, same for lxqt-panel as it will be top or left or both only atm. A separate bar providing the taskmanager (waybar or yatbfw) is needed too. All my LXQt-Wayland related settings are in ~/.config/lxqt-wayland.

When pcmanfm-qt --desktop is running inside lxqt-session apps can be started using it as wrapper (.desktop files need to be "trusted") and the will be closed by lxqt-logout --leave (which cannot close the compositor, I'm using a fork of wl-logout to logout).

binding_terminal = <super> KEY_ENTER | <super> KEY_T
command_terminal = pcmanfm-qt '/usr/share/applications/qterminal.desktop'

Mouse and keyboard settings are working only under xwayland atm:
env QT_QPA_PLATFORM=xcb /usr/bin/lxqt-config-input

A wrapper script (could at session start import from session.conf in wayfire.ini the settings wayfire supports (or the plugin syncs them at change) for [keyboard], [mouse] and [touchpad]

My experimental files are here.

[marcusbritanicus]

@stefonarch why would we need window rules if we use a plugin? The plugin can actually do a lot of work, including but not limited to starting shell components and placing them, dynamically reloading the panel configurations, and starting autostart apps.

The existing tasks plugin can be easily expanded to work on wayland without affecting it's X11 performance. Alternatively, we can also write a separate plugin for Wayland tasks. But, in both cases, we won't get workspaces support.

[marcusbritanicus]

Happily introducing the LXQt Desktop Shell Plugin for wayfire.

The past few days, I have been working on this plugin. @stefonarch has been very kind to test it and help me with various details I needed to implement this. Please test and feel free to give feedback..

@tsujan

[ludg1e]

Just adding my perspective, wayfire is more mature than labWC regarding eye candy aspects which I think are important for users since a transition from X to wayland should be as smooth as possible for them in the visual side.

But I'm guessing by common sense that the interest is more driven towards labWC as it aims at supporting the Openbox spec which in that case is less work which again is a good thing as themes won't need to be rewritten for for e.g wayfire

(probably better to mark as off-topic right?)

[stefonarch]

As far as I can see it will be the same situation as with WMs on x11: no default compositor - LXQt can be used with any wlroots based compositor.. And we don't fiddle with themes for WMs, that's up to distros.

I've used wayfire as daily driver at the time the LXQt-plugin was working (until some precise checkout for 0.7), now it has still to be refactored to work with 0.8.

Wayfire may have many eye candies (which are "out of scope" in labwc) but window decoration/theming/menu is not nearly on the level of labwc and the "everything is a plugin" architecture may not be as stable as labwc actually is (no crash never).

[tsujan]

In LabWC, the emphasis is on stability and usability. It doesn't have eye candy.

I'm one of those users who thought they couldn't work under a WM/compositor without animations, shadows, blur effects — and I admire what they've done in Wayfire. Yet I've got so "addicted" to LabWC+LXQt that I can't leave it for anything else. Once set up appropriately, it just gets out of your way and lets you really use it.

[AzumaHazuki]

I like the idea of this being possible, but it's going to cause some serious confusion with users. Plasma and GNOME don't look different between X/Wayland, but LXQt will if we go this route.

[AzumaHazuki]

Let me rephrase that: KWin and Mutter don't look different between X/Wayland, but Openbox and LabWC do.

[marcusbritanicus]

That is quite expected, and to a good extent unsurprising. While KWin and Mutter - both X11 and their Wayland counterparts are built by the same team. They would want to make everything look similar.

On the other hand, OpenBox and LabWC are built by different people (AFAIK, please correct me if I'm wrong) and have no reason to make them appear the same. This will automatically reflect in LXQt/LWQt.

I believe it might be able to theme LabWC to make it appear similar to OpenBox The same holds for Wayfire. It is worth noting that r-pi switched from X11 to Wayfire in their Pi OS 5, and they have shipped their own decoration plugin to make it appear identical to the decorations in their older X11 version.

[tsujan]

Yes, with DE-agnostic compositors, the "default" looks and feels depend on distros.

This is how my current LabWC+LXQt looks like:

Apart from compositing (which Openbox didn't provide) and a much better performance, it's very similar to my old Openbox session.

And this was my previous Wayfire+LXQt session.

The window shadow wasn't provided by Wayfire itself but by an external plugin.

I don't use LXQt Panel only because its task-bar doesn't work under Wayland — otherwise, it can be used without task-bar under LabWC (under Wayfire, external plugins are needed again, not only for LXQt Panel, but also for PCManFM-Qt's desktop and LXQt notifications).

[AzumaHazuki]

Yes, the "default" look and feel depends on the distro. But most distros don't seem to ship anything to that effect, effectively putting the ball back in our court for "default look and feel."

If LabWC implements 1:1 theme compatibility with Openbox the issue is (mostly) moot. The next best option I can think of is moving to KWin for both X11 and Wayland sessions, if that can be done without bringing in a tremendous load of KDE dependencies. We'd probably need to chunk out the KWin Settings KCM into its own little module, too.

[tsujan]

This page is about Wayfire.

The main discussion started since 2014, when Wayland wasn't really usable (in that time, GitHub didn't provide a Discussions section). Some comments were made by those who really tested different Wayland compositors, some not. KWin was discussed and tested several times (in short, it's too dependent on KDE stuff). In that long discussion you can also find several other suggestions, why some of them didn't survive, why some others weren't (or aren't) stable, etc.