wlr_seat_pointer_notify_button delivers to the surface that currently has pointer focus. If the last wl_update_pointer_focus call was during a motion event that targeted a different area (e.g., titlebar), the XWayland client surface might not have focus when the user clicks on its content area. Added wl_update_pointer_focus call before wlr_seat_pointer_notify_button in handle_pointer_button to ensure pointer focus is always current.
W_FindViewAtPoint finds the correct child view (slider, checkbox, etc.) but does not adjust event coordinates. The WMEvent x/y were set relative to the top-level WINGs view (fb->x, fb->y origin), while widget event handlers (getSliderPart, valueForMousePoint, etc.) expect coordinates relative to the widget view itself. Fixed by computing the accumulated offset from the target view up to the toplevel and subtracting it from the event coordinates. Applied to both handle_pointer_button and handle_pointer_motion.
handle_pointer_motion enqueued WME_MOTION events with target=NULL. On button press, handle_pointer_button correctly resolves the WINGs child view (slider) via W_FindViewAtPoint and sets _view_target, so the slider receives the press and sets dragging=1. But subsequent motion events had NULL target, so WMHandleEvent routed them to the top-level view instead of the slider view — the slider never received WME_MOTION during drag. Fix: add W_FindViewAtPoint resolution in handle_pointer_motion, matching the button press logic.
Two issues: (1) Texture was rendered with WREL_RAISED which added a thick bevel border, making the 8px-tall resizebar appear too small. Changed to WREL_FLAT to match X11 behavior. (2) Corner indicator light color used +40 per channel but X11 uses +80 (ROperateLine RAddOperation with cdelta=80). Changed light delta from +40 to +80 so indicators are as visible as X11.
The Wayland backend wl_frame_paint rendered the resizebar texture but never drew the corner grab handles or top bevel lines that X11 includes. Added pixman-based rendering of: (1) top bevel lines (dim at y=0, light at y=1), (2) left corner grab handle (two vertical lines from y=2 to bottom), (3) right corner grab handle (two vertical lines from y=2 to bottom). Light/dim colors are derived from the rendered texture pixel at the resizebar center (+/- 40 per channel).
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.
Window Maker
Ollie
Ollie
Ollie