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.
WMEButton and WMEMotion are separate structs in the WMEvent union with different field layouts — u.motion.x is at a different memory offset than u.button.x. The WME_BUTTON_PRESS handler in wslider.c was calling valueForMousePoint(sPtr, event->u.motion.x, event->u.motion.y) which reads uninitialized memory on Wayland (memset zero = 0). On X11 this happened to work because the X11 event translator writes to both union members. Fix: changed all event->u.motion.x/y references to event->u.button.x/y in the WME_BUTTON_PRESS case.
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.
Slider value changes (from click, drag, or programmatic set) call paintSlider to draw the new knob position into the pixman backing buffer, but the backing was never committed to the scene graph on Wayland. Added W_RedisplayView(slider->view) after each paintSlider call in: WMSetSliderValue, WMSetSliderMinValue, WMSetSliderMaxValue, and handleActionEvents (WME_MOTION/WME_BUTTON_RELEASE). The expose handler path does NOT get W_RedisplayView to avoid recursion.
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.
Window Maker
Ollie
Ollie
Ollie