The font prefs panel crashed because wl_resize called wl_redisplay
while already inside a redisplay. This caused expose handlers to
trigger more resizes, creating unbounded recursion and memory growth
(backing images growing to 1024+ pixels wide). Skip the redisplay
from wl_resize when wl_redisplay_depth > 0 — the ongoing parent
redisplay will composite the resized child at its new size.
The previous source-only clamp was insufficient. Also check that both
src and dst have non-NULL pixel data, and clip the composite region to
the destination image dimensions to prevent out-of-bounds writes.
During W_RealizeView the WME_EXPOSE handler can trigger child resizes
that make view->size exceed the backing image dimensions. Clamp the
composite width/height to the source image actual size to prevent
out-of-bounds reads in pixman_image_composite32.
Font prefs panel crashed in pixman_image_composite32 during W_MapView
because a child view had zero width/height. Skip compositing for
zero-sized views.
In Wayland mode the X11 display is NULL. WMCreateColorWell calls
WMRegisterViewForDraggedTypes which calls XInternAtom, crashing.
Bail early when display is NULL since X11 DnD is not available.
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.
The close button press from the compositor sends xdg_toplevel.close,
but the handler only set a flag without notifying the WINGs event
system. Synthesize a WME_CLIENT_MESSAGE with deleteWindowAtom so
the window closeAction callback fires and the app shuts down
gracefully.
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).
Redisplaying just posVF was insufficient; redisplay the entire posF
parent frame to ensure the icon position indicator renders at its
new location immediately after a button click.
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.
Without an explicit wl_display_flush after wl_surface_commit, protocol
requests were buffered until the next event loop iteration. This caused
visual updates (like the icon position preview in WPrefs) to appear one
interaction behind.
The posV widget was moved/resized but the parent frame (posVF) was
never redrawn, so the visual update only appeared on the next event
that triggered a redraw. Add WMRedisplayWidget after the move.
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 Wayland event backend stub for send_wm_command was a no-op, so
WPrefs settings changes never triggered a reread in the running wmaker.
Now sends SIGUSR2 to the parent process (wmaker) on "Reconfigure",
causing wDefaultsCheckDomains to run and apply changes immediately.
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.
Widgets that paint directly to their view backing (fill_rect,
draw_line, W_DrawRelief, W_PaintText) without going through the
DOUBLE_BUFFER pixmap_copy path never triggered a surface commit.
The painted content stayed in the pixman buffer but was never
submitted to the compositor — making popup menus, radio buttons,
text fields, sliders, and other controls appear empty/stale.
Fix: W_WLClientCommitAllToplevels() iterates all mapped toplevels
and commits their surfaces. Called from wl_flush() which runs once
per event loop iteration (in waitForEvent). This ensures any
direct-paint operations become visible on the next frame regardless
of which render path was used.
Both were no-op stubs returning 0/False. Editmenu uses these to
compute the original screen position of an item before drag-and-drop,
then animates the item back to that position via slideWindow on
revert. With both returning 0, the slide animation moved popups
from where they were to (0, 0) instead of back to their origin —
producing the 'menus moving on their own' effect.
translate_coordinates: walk up from src view accumulating pos.x/y
to compute the position relative to the toplevel.
get_window_geometry: return the view's pos/size directly.
paintMenuEntry was only called for the highlighted item on expose.
On X11 the X server auto-filled the rest of the window with the
background pixel, so unpainted items looked grey-but-empty. On
Wayland the buffer starts transparent — unpainted items showed
through to whatever was behind, making the popup invisible.
Iterate all items in the expose handler so the menu's full content
is visible when it first appears.
When a popup toplevel is destroyed (e.g., menu editor submenu closes),
its WLClientToplevel struct is freed. If wlc_kbd_focused or
wlc_ptr_focused pointed to it, subsequent input events dereferenced
the dangling pointer and crashed (saw it in keyboard_handle_leave).
Clear both refs in wl_client_view_destroy_backing before freeing.
Two issues:
1. Popups rendered behind their parent toplevel because the scene node
wasn't raised on apply. Add wlr_scene_node_raise_to_top so popups
appear above the parent.
2. When the parent toplevel moved, popups stayed at their old screen
position. In wl_window_move (compositor-side), after a regular
toplevel's position changes, iterate all popups and re-apply those
whose popup_parent is this toplevel so they track the parent.
paintEditMenuItem always filled with scr->white. On X11 the per-window
background was rendered by the X server based on WMSetWidgetBackgroundColor.
On Wayland we have to draw it ourselves.
Use the view's stored backColor if set; default to white otherwise.
Also set the default background of non-title items to grey at creation
time (previously only title items got an explicit colour, so non-title
items had a NULL backColor and rendered white).
editmenu.c switched on event->type (which is a WMEventType enum) but
the case labels used X11 event names (Expose, DestroyNotify, ButtonPress,
ButtonRelease, MotionNotify). These are different numeric values, so
no case ever matched — menu items never painted, never received clicks,
never handled drag.
Replace with WME_EXPOSE, WME_DESTROY, WME_BUTTON_PRESS, WME_BUTTON_RELEASE,
WME_MOTION.
The previous version had set_position(x, y) in compositor-global
coordinates, but Wayland clients don't know their toplevel's screen
position — the editmenu and popup button code naturally compute
positions relative to the parent toplevel via accumulated view->pos.
Add set_parent(xdg_toplevel) request. When a parent is set,
set_position(x, y) is interpreted as offsets from the parent
toplevel's top-left corner.
Compositor side resolves the parent's wl_toplevel_view via
wlr_xdg_toplevel_from_resource → wl_find_view_by_xdg_surface,
then adds parent->x and parent->y to the requested offsets.
Client side (wclient_wl.c) tracks the first non-popup toplevel as
ctx->main_toplevel and calls set_parent on every popup wrapper to
anchor it to the application's main window.
Window Maker