Labwc: Wlroots-based window-stacking compositor for Wayland, inspired by openbox

72 points by NeutralForest 6 days ago | 16 comments

fishgoesblub 6 days ago |
> it cannot be controlled with dbus, sway/i3-IPC or other technology. The reason for this is that we believe that custom IPCs and protocols create a fragmentation that hinders general Wayland adoption.
If anything, this leads to more fragmentation since now you have to hack your own way to control it, rather than using something standard (at least on Linux) like dbus.
jchw 6 days ago |
You can only really do that by forking though, so it's probably not going to happen. That said, the unspoken part of that is that it supports Wayland protocols for the features that would be provided by dbus/swaysock/etc. so you can just use "stock" tools like wlr-randr and sfwbar to manage outputs or provide a task switcher. Some of these protocols are still wlroots extensions (though that doesn't mean you won't find them supported elsewhere) but increasingly those are being replaced with standard protocols (with the caveat that GNOME Mutter will probably never implement any of them, but I'm not sure if anyone cares; GNOME is probably going to wind up just being it's own thing that is technically Wayland but not how anyone else does it.)
(P.S.: I suspect Swaysock might've never existed if it were not for the fact that Sway is more or less a direct recreation of i3wm as a Wayland compositor; it is the equivalent of i3 IPC. You can and should just use Wayland protocols even in Sway where possible.)
resonious 6 days ago |
Right... I do not follow how using a standard creates fragmentation.
jchw 6 days ago |
DBus is just an RPC layer. You still need to define a standard DBus interface for any given feature. Not all UNIX-likes ship DBus in the base system (which is certainly one component of why Sway has Swaysock.)
Meanwhile, every Wayland compositor speaks at least the core Wayland protocols and probably some of the extensions, and they all go through the same standardization process, whereas there's certainly no such process for DBus or random UNIX domain sockets based protocols. It's simpler to just use Wayland protocols where possible.
Starlevel004 6 days ago |
> rather than using something standard (at least on Linux) like dbus.
What standard? Other compositors have their own specific protocol to talk to it even if it's done other dbus.
ashleyn 6 days ago |
Soon: There are now 15 competing standards.
solarkraft 5 days ago |
The wlroots extensions are one attempt at creating such a standard, being used by pretty much all compositors except for KDE and Gnome. The issue with that is of course that all wlroots compositors combined have a tiny market share compared to either.
bean-weevil 6 days ago |
The configuration being written in xml makes me feel like I am not the target audience for this program.
onli 6 days ago |
Well, that's openbox for you. Openbox though used the XML quite nicely to enable GUI configuration (never looked into the code, I assume they did not implement it just with regexps...), so there is that advantage at least.
c45y 6 days ago |
Having made the switch from sway to labwc nearly a year ago I've edited the config maybe all of 3 times
It's xml but at least it's plain and well documented with sensible defaults
jmclnx 6 days ago |
There is also waybox
https://github.com/wizbright/waybox
Glad these 2 projects exist since I would want fvwm (prefered) or a fluxbox clone under wayland when I am forced to move
hakfoo 5 days ago |
Nobody seems to be addressing the themability of the window borders/titlebar itself anymore. It's weird, because that was a big part of the Cambrian explosion of X11 window managers back in the day-- so many options and so much customization. It was a selling point-- people would go out of their way to run things like Enlightenment with over-the-top themes.
Even labwc's stated "let's try to be Openbox-theme-compatible" goal is highly limited (see support tickets with various missing features) and plenty of other compositors seem to have just limited, baked-in decorations or promises "a plugin ecosystem will appear and fill the hole".
The closest I've seen is Wayland Maker, which at least has a clear focus of "let's copy a recognizable X11 look and feel" but it's a few releases shy of daily-driver, and arguably targets a relatively low-hanging fruit (WindowMaker lacks some of the elaborate scriptability and functionality of FVWM)
I suppose part of this might be because of Client-Side Decoration, where half the software says "I reject your titlebar and substitute my own", but I feel like we're nowhere even at "You can easily get a 1:1 pixel match of the LOOK of your FVWM/CTWM/Openbox desktop", let alone all the weird little feel rules and tools that have developed over the decades. Does anyone even do a pager or equivalent for FvwmButtons on Wayland, or is it all uber-minimal "bars"?
TBH, that's why I try Wayland for about 20 minutes every 3 months and bounce off. I feel like I'm being told I have to accept less. Even if I accept the weird compromises Wayland expects (replacing direct media player and volume control access to hotkeys with a set of compositor bindings and workaround tools, finding a substitute for XScreensaver to protect/exercise my expensive new OLED monitor, probably shop for a new terminal), I still can't make it look and feel like home.
jmclnx 5 days ago |
>TBH, that's why I try Wayland for about 20 minutes every 3 months and bounce off
You lasted longer than me. I tried it once for 10 minutes and went back to X. I never looked back. I dread the day X is no longer supported. I think that will happen once Red Hat (IBM) and/or freedesktop.org forces Mozilla to support only Wayland.
sillystuff 6 days ago |
I played around with this in a VM the last time it was mentioned on HN.
The thing I want to do, but wasn't able to find a way to accomplish was to have a virtual desktop switcher gadget and a separate gadget to swallow minimized applications where each can be placed independently on the screen (and preferably auto hide)-- this will be separate application(s) from Labwc, but I did not find anything for Wayland that could do this (I do not like the MS Windows style task bar with menus, desktop switcher, etc., in one single bar).
Anyone have any suggestions?
Another nice to have would be to have screen edge bindings, where moving the mouse pointer or dragging a window over an edge, or corner, of the screen can be made to take an action. I'm not sure if this could even be accomplished with a stand-alone utility under Wayland, or if this must be done by the compositor. But, if possible, and anyone knows of something that exists, I am all ears.
One of the things I liked with labwc is that you can have traditional X style application menus by right-click/left-clicking the root window (it is not the default, but was easy to setup).
heresie-dabord 6 days ago |
I can help with the virtual desktop switcher...
Edit "~/.config/labwc/rc.xml" to add the following:

<windowSwitcher show="yes" preview="yes" outlines="yes" allWorkspaces="yes"> <fields> <field content="type" width="25%" /> <field content="trimmed_identifier" width="25%" /> <field content="title" width="50%" /> </fields> </windowSwitcher>
<desktops> <number>4</number> <prefix>ws</prefix> </desktops>
<keyboard> <default /> <keybind key="C-A-Left"> <action name="GoToDesktop" to="left" wrap="yes"/> </keybind> <keybind key="C-A-Right"> <action name="GoToDesktop" to="right" wrap="yes"/> </keybind> </keyboard>
solarkraft 5 days ago |
> Labwc only understands wayland-protocols & wlr-protocols, and it cannot be controlled with dbus, sway/i3-IPC or other technology. The reason for this is that we believe that custom IPCs and protocols create a fragmentation that hinders general Wayland adoption.
One thing that really hinders adoption is incompatibility - and the biggest Wayland compositor being Gnome, the dbus protocol is the most popular. There is a bit of a wlroots ecosystem, but it’s only in third place behind Gnome and KDE.