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.
Remove completed planning documents (WAYLAND_ROADMAP.md, ACTION_PLAN.md,
ACTION_PLAN_PROMPTS.md). Update ARCHITECTURE.md and BACKEND_ABSTRACTION.md
with current file sizes and completion status. Add ROADMAP.md covering
remaining work prioritized for daily-driver use.
Three issues prevented WPrefs from being managed by wmaker in X11:
1. W_X11OpenDisplay: XOpenDisplay("") fails; treat empty string as NULL
so it falls back to DISPLAY env var.
2. wevent_x11.c/wevent.c: MapRequest and ConfigureRequest events must
bypass WINGs view lookup (both _view_target in x11_fetch and
W_GetViewForWindow in WMHandleEvent) to reach DispatchEvent via
extraEventHandler.
3. wview_x11.c: x11_create_root must use RootWindow() not
scr->rootWin (which may be an intermediate window created by
RCreateContext for non-default visuals). Otherwise toplevel
WINGs windows are created as children of the wrong parent and
their MapRequest never reaches the WM.
WPrefs.app/main.c defaults display_name to "" (empty string).
W_X11OpenDisplay passed this directly to XOpenDisplay, but
XOpenDisplay("") is not equivalent to XOpenDisplay(NULL) — the
former fails while the latter uses the DISPLAY environment variable.
Treat empty display string as NULL so XOpenDisplay falls back to
the environment variable.
Also remove debug traces from event.c and x11_backend.c.
SubstructureRedirect events (MapRequest, ConfigureRequest) are delivered
to the root window. Since the root window has a WINGs view registered
(the WMScreen root view), W_GetViewForXWindow resolves it and
WMHandleEvent dispatches to the view handlers instead of falling through
to extraEventHandler (DispatchEvent).
This caused WINGs-based apps like WPrefs to never have their windows
managed by the WM - the MapRequest was silently consumed.
Fix: skip the view lookup for MapRequest and ConfigureRequest events so
they always reach DispatchEvent via extraEventHandler.
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
Selection and mapping events have mask 0 in the type table (matching
X11 semantics where they bypass event masks). Change the dispatch
check to deliver events with mask==0 to all registered handlers,
so these events are not silently dropped.
The wmeMaskForType table had WME_CLIENT_MESSAGE mapped to 0, so
WMHandleEvent never dispatched client messages to registered handlers.
The window close handler (registered with ClientMessageMask) was never
called. Set the correct mask so the deleteWindow protocol works.
The poll-based wlclient_dispatch with timeout 0 missed events that
were already buffered. Use prepare_read/read_events/dispatch_pending
which reads whatever is available on the socket without polling.
Ollie
Window Maker
Ollie
Ollie
lkn