findMenu only checked root_menu and switch_menu, so the window
menu (right-click titlebar) was never found during mouse tracking.
Add window_menu and its cascades to the search.
- Use wlr_backend_autocreate for standalone mode (from TTY) instead of
headless-only. Gives real DRM/KMS output + libinput.
- wl_update_pointer_focus: skip client surface focus when pointer is
over an internal frame_buf (menu, titlebar). Prevents client from
stealing cursor/events from WM chrome.
- wl_focus_set: ensure seat keyboard is set and flush clients before
sending keyboard.enter so client has processed wl_seat.capabilities.
- Renderer and allocator use the autocreated backend in standalone mode.
findMenu was returning y relative to the frame top (including titlebar).
getEntryAt expects y relative to the content area. Subtracting top_width
means pointer in titlebar gives y<0 → entry_no=-1 (no selection), which
is correct behavior matching the X11 path.
The root menu uses a 'brother' copy for the live instance. findMenu
was only checking the original, not the brother, so it returned NULL
when the pointer was over the active menu copy. This caused the menu
to close immediately on button release (closeCascade triggered by
!smenu condition).
All WFrameWindow callbacks (on_mousedown_titlebar, on_dblclick_titlebar,
on_mousedown_resizebar, on_click_left, on_click_right, on_dblclick_right)
now take WMEvent* instead of XEvent*. This fixes the crash when clicking
the menu titlebar in Wayland mode (_x11_raw was NULL).
Affected files: framewin.h, framewin.c, menu.c, window.c, dialog.c,
winspector.c. All verified X11-free with nm.
findMenu always returned NULL because the refactored code set win=0
then checked 'if (win == None) return NULL'. Replace with geometric
bounds checking against mapped menus. This fixes the menu disappearing
on button release (closeCascade was called because smenu was NULL).
- Entry separators: light line on top, dark line on bottom between entries
- Left/right bevel edges on each entry
- Cascade arrow (triangle) for submenu entries
- Paint menu frame title bar (wl_frame_paint) when menu is shown
- Matches X11 menu_draw_frame behavior
In X11, mapping a window triggers Expose which causes repainting.
In Wayland there are no Expose events, so wMenuPaint must be called
explicitly after the menu is mapped in wMenuMapAt.
Add vtable slots: icon_select, icon_change_title, clip_icon_paint,
drawer_icon_paint, balloon_init, do_kaboom, menu_paint_entry,
menu_draw_frame.
Replace policy call sites with vtable dispatch. Make paintEntry and
drawFrame in menu.c non-static as wMenuPaintEntry/wMenuDrawFrame.
X11 backend calls the mechanism functions; Wayland backend is no-op.
wFrameWindowPaint now only reached through X11 backend's frame_paint.
Key changes in wl_backend.c:
- wl_atom_intern: call XInternAtom on XWayland display (was returning 0)
- Add wl_or_view struct to track override_redirect XWayland surfaces
- handle_xwayland_new_surface: composite OR surfaces via scene graph
- frame_create_toplevel/child: create real X11 windows on XWayland
- frame_destroy/configure: delegate to Xlib
- window_map/unmap/move/resize: fall through to Xlib for frame windows
- stacking_raise/lower: update scene graph + Xlib fallback
- event_flush/sync: call XFlush/XSync on XWayland display
- window_set_border/border_width/clear: delegate to Xlib
- window_get_rect: query XWayland geometry for non-toplevel windows
Note: frame creation via XWayland is a temporary bridge. The correct
architectural approach is native scene-buffer rendering with pixman.
Levi Neely
Levi Neely