The overlay drawing functions (wl_overlay_draw_rect, wl_overlay_draw_line) write XOR pixels to a client-side pixman buffer but never flushed it to the scene graph. On X11, each XDrawRectangle is immediately processed server-side, so the wireframe appears in real-time. On Wayland, the overlay buffer was only flushed in wl_server_ungrab() at the END of the resize operation. Added overlay_flush() after each draw call so each XOR batch is pushed to wlr_scene_buf and rendered immediately.
Two bugs in geomview.c: (1) Missing backing commit on Wayland - paint() wrote to pixman backing but never pushed to scene graph. Added W_RedisplayView() after paint() in both WSetGeometryViewShownPosition and WSetGeometryViewShownSize. (2) Expose event handler used case Expose: (X11 constant value 12) instead of case WME_EXPOSE: (WINGs enum value 8) - harmless on X11 where Pixmap content is server-persistent, but broke Wayland where the expose handler is the re-draw mechanism after wl_redisplay fills the backing with bg color.
The blue position indicator (gview — geometry view with blue-gray background,
white coordinate text) was visible during window move, but never disappeared
when the move ended.
Root cause: W_ViewSceneNodeSetEnabledFn was declared in wview_wl.c and
called by wl_unmap() to disable the view's scene buffer node, but
wl_backend.c never wired it up — the pointer was NULL.
Also: add auto-create of frame_buf for WINGs toplevel views not explicitly
reparented (switch panel, menus, gview), sync position from WINGs view on
commit, auto-realize children in wl_map/wl_map_subviews, and guard scene
node enablement against unmapped views.
Menu entry painting:
- Add drawFrame() calls for 3D beveled entries (WTEX_SOLID)
- Add menu_text_clearance to text Y positioning
- Add left-side indicator drawing (radio/check/snap pixmaps)
- Add indicator X offset (MENU_INDICATOR_SPACE)
- Fix disabled+selected text color
- Fix texture-aware background clearing
- Add cascade arrow for submenu entries
Balloon tooltips:
- Implement x11_balloon_show() with text and mini-preview rendering
- Previously was a no-op stub
Clip arrows:
- Draw workspace-switching triangles on clip icon
- Previously stubbed out
Event handling:
- Add MapRequest, ConfigureRequest, ReparentNotify translation to
xev_to_wme() in WINGs/wevent_x11.c
- These WM-critical events were silently dropped, preventing new X
clients (e.g. xterm) from being managed
In-process WINGs clients have their own wl_display connection that
needs to be dispatched for xdg_toplevel.close to be received. Add
W_WLClientDispatchPending() and call it each main loop iteration
so protocol events reach the client-side handlers promptly.
The xdg_toplevel.close protocol message requires the client to dispatch
its wl_display, but in-process WINGs clients may not do so promptly.
Directly enqueue the WME_CLIENT_MESSAGE/deleteWindowAtom event from
wl_client_close so the closeAction fires on the next WINGs event drain.
Menu background colors were hardcoded. Now uses:
- scr->select_color for selected item background
- scr->menu_item_texture->normal for unselected background
- scr->menu_item_texture->dim/light/dark for cascade arrow
Text colors already used scr->select_text_color, mtext_color, dtext_color.
Replace the filled triangle with three lines matching the upstream X11
implementation: a dim top edge, light bottom edge, and dark left edge,
forming a 3D right-pointing triangle indicator for submenu entries.
The triangle was drawn with increasing width from left to right,
making it point left. Reverse the vertical span so the widest part
is on the left and it tapers to a point on the right.
WINGs timers (used by workspace name fade animation) were never firing
because the compositor event loop never called W_CheckTimerHandlers.
This function is normally invoked by WMNextEvent, but the compositor
uses a custom loop. Add the call so timers fire each iteration.
The workspace name display was rendering with an opaque black background
and never fading out. Fix by:
- Using transparent (alpha=0) background instead of black
- Returning RGBA images from badge_render and badge_get_background
- Preserving alpha channel in badge_update instead of hardcoding 0xFF
This allows the fade animation (RCombineImagesWithOpaqueness) to work
correctly, blending text with decreasing opacity over a transparent
background until the badge disappears.
WINGs button callbacks trigger wl_redisplay which commits the client
surface, but the compositor only processes that commit on the next
wl_event_loop_dispatch. Add a zero-timeout dispatch after handling
WINGs events so client commits are processed immediately, making
the next scheduled frame render the updated content.
Also revert posF redisplay back to posVF (posF caused gray flash).
The extra wlr_scene_output_commit broke frame pacing in nested mode by
consuming the host frame callback. Instead, move wlr_output_schedule_frame
to after wl_event_loop_dispatch so client commits processed during
dispatch are rendered on the next frame event.
Client surface commits arrive during wl_event_loop_dispatch but may be
processed after the frame event has already rendered the old state. Add
an additional wlr_scene_output_commit after dispatch to immediately
pick up any new client content, fixing the one-interaction-behind
visual update issue in WINGs clients like WPrefs.
SIGUSR2 is fundamentally unsafe in a multi-threaded compositor: library
threads (pango fontconfig) created after pthread_sigmask receive the
signal and crash. The Wayland event loop already has inotify watching
the defaults directory, so file changes are detected automatically
without any explicit signaling.
The early pthread_sigmask(SIG_BLOCK, SIGUSR2) is retained as a safety
measure to prevent stray SIGUSR2 from terminating the compositor.
SIGUSR2 was being delivered to pango fontconfig threads instead of the
signalfd because those threads were created before the signal mask was
set in wl_event_loop_run. Block SIGUSR2 at the very start of real_main
so all threads (including library-spawned ones) inherit the blocked
mask and the signalfd is the sole recipient.
SIGUSR2 was not in the signalfd set, so it was delivered asynchronously
to the old signal handler which set WSTATE_NEED_REREAD. But the Wayland
event loop never checked that state flag, and the signal delivery itself
could crash the compositor.
Add SIGUSR2 to the signalfd set and handle it synchronously within the
event loop by calling wDefaultsCheckDomains directly.
The previous getppid() approach sent SIGUSR2 to the terminal process
(foot) rather than wmaker, killing the shell. Now wmaker exports
WMAKER_PID at startup and wl_send_wm_command reads it to signal the
correct process.
The xcursor manager was hardcoded to NULL theme with size 24. Now reads
XCURSOR_THEME and XCURSOR_SIZE from the environment, matching the
behavior of other Wayland compositors like Sway.
The XWayland focus path only called wlr_xwayland_surface_activate (X11
focus) but did not notify the wlr_seat about keyboard focus. Without
wlr_seat_keyboard_notify_enter, key events were never forwarded to the
XWayland surface via the Wayland transport.
Now wl_focus_set for XWayland surfaces sets the seat keyboard and calls
wlr_seat_keyboard_notify_enter, matching the XDG toplevel path.
The map_request signal was never firing for managed XWayland surfaces,
preventing scene node creation and window management. Switch to the
standard wlroots 0.19 lifecycle: listen for associate (surface attached),
then hook surface->events.map (content committed) before creating the
scene node and calling wManageWindow.
Also fix wl_window_get_client_attrs to report VIEWABLE based on surface
existence rather than surface->mapped, since X11 geometry (xw->width/height)
is available before the wlr_surface maps.
xterm starts with a 10x17 pixel window. The initial configure was
sending that size back (since > 0), so xterm rendered at 10x17.
Now use 640x480 default when the initial size is < 64px.
The associate signal fires when a wlr_surface is linked to the
xwayland surface, but this can happen before or during new_surface
processing. map_request fires when the X11 client actually sends
MapRequest — at which point WM_CLASS is set and the client is ready
to be managed and shown.
If the xwayland surface already has a wlr_surface when we register
listeners (associate event already fired), trigger the map handler
directly. This fixes xterm and other X11 clients that associate
their surface before the new_surface handler runs.
xterm and other X11 clients create a small initial window then resize.
At map time, xw_surface->width/height may still be the initial tiny
value (e.g. 10x17). wManageWindow reads this and creates a tiny frame.
Use 640x480 as fallback when width/height <= 1.
X11 clients (like xterm) create their window first, then set WM_CLASS
before mapping. The previous code skipped surfaces that had no class
AND no title at new_surface time, marking them override_redirect. This
prevented xterm and other well-behaved X11 apps from ever being managed.
Fix: log a warning but continue registering listeners. The surface will
be managed when it maps (associate signal) at which point WM_CLASS is
typically set.
Ollie
Window Maker
Ollie
Ollie