A Wayland window-stacking compositor https://labwc.github.io
Find a file
John Lindgren 3be8fe25f3 xdg: handle initially maximized xdg-shell views better
Currently, initially maximized (or fullscreen) xdg-shell views exhibit
one of two issues:

 - some (e.g. GTK and Qt apps) paint an initial frame un-maximized
   (before the "map" event) and only maximize in a later commit

 - others (e.g. foot) maximize immediately without flicker, but never
   store a valid natural size, so we end up using a fallback (640x480)

Under KWin, neither of these issues occur, so I looked into what labwc
is doing wrong. It seems that:

 - wlroots internally sends an initial configure event with a size of
   0x0 to all xdg-shell views. This requests the client to set its own
   preferred (a.k.a. natural) size.

 - For an initially maximized/fullscreen view, the initial configure
   event should contain the maximized/fullscreen size rather than 0x0.
   In labwc, this means we have to call wlr_xdg_toplevel_set_size()
   earlier, i.e. from the new_surface event. Tracing with WAYLAND_DEBUG
   shows that the initial configure event now has the correct geometry,
   matching KWin behavior. With this change, GTK and Qt apps no longer
   paint an incorrect un-maximized frame.

 - However, this means that all xdg-shell views now suffer from the same
   issue as foot, where we never receive a commit with the un-maximized
   (natural) geometry. The correct way to get the natural geometry seems
   to be to wait until we want to un-maximize, and send a configure
   event of 0x0 at that point.

Sending a configure event of 0x0 when un-maximizing is a bit annoying as
it breaks some assumptions in labwc code. In particular:

 - view->natural_geometry may now be unknown (0x0), requiring various
   wlr_box_empty() checks sprinkled around. I added these in all the
   obvious places, but there could be some code paths that I missed.

 - Positioning the newly un-maximized view within view_maximize() no
   longer works since we don't know the natural size. Instead we have to
   run the positioning logic from the surface commit handler. This
   results in some extra complexity, especially for interactive move.
   See the new do_late_positioning() function in xdg.c.

Some TODOs/FIXMEs (non-blocking in my opinion):

 - The view_wants_decorations() check is now duplicated in both the
   new_surface and map event handlers. I'm not sure if this is necessary
   but it seemed like the safest approach for now. More testing would be
   nice, particularly with various combinations of config and client SSD
   preferences.

 - Aside from the interactive move case, the "late positioning" logic
   always centers the view when un-maximizing, and does not invoke any
   of the smart placement logic. If we want to invoke smart placement
   here, I'd appreciate someone with more knowledge of that code to take
   a look and figure out how to do that correctly.
2024-07-19 22:48:39 +01:00
.github/workflows CI: switch Arch and FreeBSD to wlroots 0.18 2024-07-17 21:28:59 +01:00
data meson.build: install badges for labwc and migrate to data/ 2024-02-03 22:05:28 +00:00
docs docs: add tablet tool section 2024-07-19 22:45:41 +01:00
include xdg: handle initially maximized xdg-shell views better 2024-07-19 22:48:39 +01:00
po Translation updates from weblate 2024-07-08 21:11:46 +01:00
protocols chase: move to stable tablet protocol and require w-p >= 1.35 2024-07-17 21:28:59 +01:00
scripts CI: add atof() to banned list 2024-05-13 11:06:04 +02:00
src xdg: handle initially maximized xdg-shell views better 2024-07-19 22:48:39 +01:00
subprojects chase: wlroots.wrap: track the wlroots 0.18 branch 2024-07-17 21:28:59 +01:00
.clang-format add .clang-format (with a disclaimer) 2024-04-18 21:52:38 +01:00
.editorconfig .editorconfig: set max_line_length=80 for *.md 2024-04-27 22:09:16 +01:00
.gitattributes Exclude checkpatch.pl from language stats 2022-12-20 22:17:10 +00:00
.gitignore exclude IDE settings in .gitignore 2024-04-18 21:51:25 +01:00
CONTRIBUTING.md docs: 80 column lines (where possible), drop trailing whitespace 2024-04-07 21:54:42 +02:00
LICENSE Initial commit 2019-05-11 21:21:58 +01:00
meson.build chase: move to stable tablet protocol and require w-p >= 1.35 2024-07-17 21:28:59 +01:00
meson_options.txt CI: enable gcc static analyzer 2024-04-10 08:14:59 +02:00
NEWS.md NEWS.md: update for 0.7.3 2024-07-12 17:19:00 +01:00
README.md docs: add example shutdown file 2024-06-01 23:53:34 +02:00

labwc

[Website] [Scope] [IRC Channel] [Release Notes]

1. Project Description

1.1 What Is This?

Labwc stands for Lab Wayland Compositor, where lab can mean any of the following:

  • sense of experimentation and treading new ground
  • inspired by BunsenLabs and ArchLabs
  • your favorite pet

Labwc is a wlroots-based window-stacking compositor for wayland, inspired by openbox.

It is light-weight and independent with a focus on simply stacking windows well and rendering some window decorations. It takes a no-bling/frills approach and says no to features such as animations. It relies on clients for panels, screenshots, wallpapers and so on to create a full desktop environment.

Labwc tries to stay in keeping with wlroots and sway in terms of general approach and coding style.

Labwc has no reliance on any particular Desktop Environment, Desktop Shell or session. Nor does it depend on any UI toolkits such as Qt or GTK.

1.2 Why?

Firstly, we believe that there is a need for a simple Wayland window-stacking compositor which strikes a balance between minimalism and bloat approximately at the level where Window Managers like Openbox reside in the X11 domain. Most of the core developers are accustomed to low resource Desktop Environments such as Mate/XFCE or standalone Window Managers such as Openbox under X11. Labwc aims to make a similar setup possible under Wayland, with small and independent components rather than a large, integrated software eco-system.

Secondly, the Wayland community has achieved an amazing amount so far, and we want to help solve the unsolved problems to make Wayland viable for more people. We think that standardisation and de-fragmentation is a route to greater Wayland adoption, and wanting to play our part in this, Labwc only understands wayland-protocols & wlr-protocols, and it cannot be controlled with dbus, sway/i3/custom-IPC or other technology.

Thirdly, it is important to us that scope is tightly controlled so that the compositor matures to production quality. On the whole, we value robustness, reliability, stability and simplicity over new features. Coming up with new ideas and features is easy - maintaining and stabilising them is not.

Fourthly, we are of the view that a compositor should be boring in order to do its job well. In this regard we follow in the footsteps of metacity which describes itself as a "Boring window manager for the adult in you. Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios."

Finally, we think that an elegant solution to all of this does not need feel square and pixelated like something out of the 1990s, but should look contemporary and enable cutting-edge performance.

1.3 Why The Openbox Theme Specification?

In order to avoid reinventing configuration and theme syntaxes, the openbox 3.6 specification is used. This does not mean that labwc is an openbox clone but rather that configuration files will look and feel familiar.

Also, parsing GTK3+ and Qt themes for window decorations is very complicated, so using much simpler specs such as those used by openbox and xfwm makes sense for a compositor such as labwc, both in terms of implementation and for user modification.

Openbox spec is somewhat of a stable standard considering how long it has remained unchanged for and how wide-spread its adoption is by lightweight distributions such as LXDE, LXQt, BunsenLabs, ArchLabs, Mabox and Raspbian. Some widely used themes (for example Numix and Arc) have built-in support.

We could have invented a whole new syntax, but that's not where we want to spend our effort.

1.4 Very High Level Scope

A lot of emphasis is put on code simplicity when considering features.

The main development effort is focused on producing a solid foundation for a stacking compositor rather than adding configuration and theming options.

See scope for full details on implemented features.

High-level summary of items that Labwc supports:

  • Config files (rc.xml, autostart, shutdown, environment, menu.xml)
  • Theme files and xbm/png/svg icons
  • Basic desktop and client menus
  • HiDPI
  • wlroots protocols such as output-management, layer-shell and foreign-toplevel
  • Optionally xwayland

1.5 Videos

video link date duration
0.7.2-release-video 24-May-2024 3:17
0.6.0-release-video 31-Oct-2022 2:48
0.3.0-release-video 05-Aug-2021 1:10
pre-0.1.0-release-video 25-Feb-2021 3:42

1.6 Screenshot

The obligatory screenshot:


Screenshot description

2. Build and Installation

To build, simply run:

meson setup build/
meson compile -C build/

Run-time dependencies include:

  • wlroots, wayland, libinput, xkbcommon
  • libxml2, cairo, pango, glib-2.0
  • libpng
  • librsvg >=2.46 (optional)
  • xwayland, xcb (optional)

Build dependencies include:

  • meson, ninja, gcc/clang
  • wayland-protocols

Disable xwayland with meson -Dxwayland=disabled build/

For OS/distribution specific details see wiki.

If the right version of wlroots is not found on the system, the build setup will automatically download the wlroots repo. If this fallback is not desired please use:

meson setup --wrap-mode=nodownload build/

To enforce the supplied wlroots.wrap file, run:

meson setup --force-fallback-for=wlroots build/

If installing after using the wlroots.wrap file, use the following to prevent installing the wlroots headers:

meson install --skip-subprojects -C build/

3. Configuration

User config files are located at ${XDG_CONFIG_HOME:-$HOME/.config/labwc/} with the following five files being used: rc.xml, menu.xml, autostart, shutdown, environment and themerc-override.

Run labwc --reconfigure to reload configuration and theme.

For a step-by-step initial configuration guide, see getting-started.

4. Theming

Themes are located at ~/.local/share/themes/\<theme-name\>/openbox-3/ or equivalent XDG_DATA_{DIRS,HOME} location in accordance with freedesktop XDG directory specification.

For full theme options, see labwc-theme(5) or the themerc example file.

For themes, search the internet for "openbox themes" and place them in ~/.local/share/themes/. Some good starting points include:

5. Translations

The default window bar menu can be translated on the weblate platform.

Translation status

6. Usage

./build/labwc [-s <command>]

NOTE: If you are running on NVIDIA, you will need the nvidia-drm.modeset=1 kernel parameter.

If you have not created an rc.xml config file, default bindings will be:

combination action
alt-tab activate next window
super-return alacritty
alt-F3 bemenu
alt-F4 close window
super-a toggle maximize
alt-mouse-left move window
alt-mouse-right resize window
alt-arrow move window to edge
super-arrow resize window to fill half the output
alt-space show the window menu
XF86_AudioLowerVolume amixer sset Master 5%-
XF86_AudioRaiseVolume amixer sset Master 5%+
XF86_AudioMute amixer sset Master toggle
XF86_MonBrightnessUp brightnessctl set +10%
XF86_MonBrightnessDown brightnessctl set 10%-

A root-menu can be opened by clicking on the desktop.

6.1 Gaming

Cursor confinement is supported from version 0.6.2. If using older versions, use a nested gamescope instance for gaming. It can be added to steam via game launch option: gamescope -f -- %command%.

7. Integration

Suggested apps to use with labwc:

See integration for further details.