Skip to content

fix(wbconf): add a header bar for a proper draggable titlebar#69

Merged
ebenali merged 1 commit into
masterfrom
fix-wbconf-headerbar
Jun 21, 2026
Merged

fix(wbconf): add a header bar for a proper draggable titlebar#69
ebenali merged 1 commit into
masterfrom
fix-wbconf-headerbar

Conversation

@ebenali

@ebenali ebenali commented Jun 21, 2026

Copy link
Copy Markdown
Member

Symptom

Dragging wbconf "by the titlebar" made the window expand/"mushroom" and lose its titlebar — while other apps (Chromium, pcmanfm) were fine.

Diagnosis

With temporary instrumentation I confirmed wbconf is pure client-side decorated: want=0, no waybox frame, deco=(nil), GTK shadow-offset geometry (+14+12). GTK4 does not implement the server-side xdg-decoration protocol, so waybox correctly leaves GTK windows CSD (the SSD gating added earlier). So the misbehaviour is GTK-side, not a waybox frame.

The real gap (as you suspected — "incompleteness in wbconf"): wbconf is a GtkApplicationWindow with no titlebar widget. A decorated GtkWindow with no header bar falls back to a degenerate CSD titlebar that misbehaves under a wlroots compositor and has no proper drag/maximize affordance.

Fix

Give wbconf an explicit GtkHeaderBar via gtk_window_set_titlebar(). GTK then owns a real, draggable titlebar (a GtkWindowHandle) that drives the compositor's interactive move/maximize through the normal xdg_toplevel requests — the standard GTK4 app structure.

On your "drive a seat from the cmdline" question

Yes — that's what the Wayland virtual-input protocols are for. I prototyped a zwlr_virtual_pointer_v1 press/move/release CLI to drive drags. The blocker for reproducing this headlessly turned out to be GTK's renderer losing its surface under the headless backend (VK_ERROR_SURFACE_LOST_KHR); GSK_RENDERER=cairo makes headless GTK render, but the CSD move gesture still doesn't replay reliably. I've filed a todo to generalise that prototype into a committed, reusable scriptable-input test helper.

Testing

  • Full suite 27 green (g++/ASan); clang + release clean.
  • wbconf maps cleanly under headless waybox with the header bar, no ASan/GTK errors.
  • Interactive drag couldn't be reproduced headlessly (GTK renderer limitation noted above); this is the standard GTK4 pattern and the missing piece the symptom points to — please verify on real hardware.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

…tlebar

wbconf is a GtkApplicationWindow with no titlebar widget. GTK does not implement
the server-side xdg-decoration protocol, so waybox correctly leaves GTK windows
client-side decorated (see the SSD gating in decoration.cpp). But a *decorated*
GtkWindow with no header bar falls back to a degenerate client-side titlebar
that misbehaves under a wlroots compositor — dragging it could make the window
jump or appear to expand, and it had no proper drag/maximize affordance.

Give wbconf an explicit GtkHeaderBar (gtk_window_set_titlebar). GTK then owns a
real, draggable titlebar backed by a GtkWindowHandle, which drives the
compositor's interactive move/maximize through the normal xdg_toplevel requests.

This is the standard GTK4 application structure and resolves the broken
drag-to-move behaviour reported for wbconf.

Verified: full suite 27 green (g++/ASan); clang + release clean; wbconf maps
cleanly under headless waybox with the header bar and no ASan/GTK errors.
(Interactive drag could not be reproduced under the headless backend because
GTK's renderer loses its surface there; the fix is the standard GTK4 pattern
and the missing piece the symptom pointed to.)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@ebenali
ebenali merged commit 1e8e96b into master Jun 21, 2026
4 checks passed
@ebenali
ebenali deleted the fix-wbconf-headerbar branch June 21, 2026 16:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant