The dock_shadow was rendering above the dragged icon because:
1. It was in WL_LAYER_OVERLAY/DOCK, above the dock icons in WL_LAYER_FLOATING
2. wl_stacking_restack could not order nodes across different parent trees
3. wl_window_map auto-raised on map, undoing any prior restack
Fixes:
- Place dock_shadow in WL_LAYER_FLOATING (where WMDockLevel=5 maps)
- Rewrite wl_stacking_restack to reparent nodes into the same tree
and use wlr_scene_node_place_below for guaranteed ordering
- Remove auto-raise from wl_window_map (explicit wRaiseFrame handles it)
The dock ghost shadow was in WL_LAYER_OVERLAY rendering above dock icons.
Move to WL_LAYER_NORMAL and lower to bottom so it renders beneath the
dock icons (WL_LAYER_DOCK) during icon drag, matching X11 behavior
where the ghost shows as a position marker below the real icon.
Move the appicon_paint_dock_dots call into wIconPaint itself (after
icon_paint), so that ANY repaint of a docked appicon includes dots
and launching stipple. Previously, the dots were only drawn from
wAppIconPaint and the observers, but other repaint paths (pointer
events, window_clear) would erase them.
Remove the now-redundant calls from appearanceObserver and
tileObserver since wIconPaint handles it.
dockIconPaint was calling wm_backend->appicon_paint directly, which
bypasses wAppIconPaint and its appicon_paint_dock_dots call. This meant
docked icons never got their dots drawn at startup.
Call wAppIconPaint instead so the full paint path (tile + dots + stipple)
executes for all docked appicons.
On Wayland there are no Expose events, so when tileObserver or
appearanceObserver repaints an icon (via update_icon_pixmap or
window_clear), the dock dots drawn by appicon_paint_dock_dots
were lost. Explicitly re-trigger dock dots painting for docked
appicons after the observer repaint.
Replace the no-op wl_noop_appicon_paint_dock_dots with a real
implementation that draws:
- 3 white dots with black shadow for docked+not-running icons
- Checkerboard dimming (stipple) for launching icons
Dot geometry matches the X11 backend: positioned at 4m/9m/14m
horizontally, icon_size-6m vertically (m = icon_size/64, min 1).
wl_create_rimage_from_drawable only looked up frame_buf IDs, but
icon->pixmap on Wayland is a raw pixman_image_t* from RConvertImage,
not a frame_buf ID. When frame_buf_find fails, fall back to treating
the drawable pointer as a pixman_image_t* directly.
This fixes the ghost dock shadow (semi-transparent overlay shown
during icon drag) which was silently failing because MakeGhostIcon
returned WM_NATIVE_NONE.
The clip icon was not rendering properly because:
1. An early return prevented painting when workspaces were not yet
initialized (moved the check so base tile always paints)
2. The filled triangle arrows (top-right and bottom-left) drawn by
X11 paintClipButtons were missing entirely
Add pixel-level triangle drawing matching the X11 implementation
geometry: CLIP_BUTTON_SIZE-based sizing with 5px margins.
frame_buf_hit now walks children recursively (up to 4 levels) instead
of only checking immediate children of top-level frames. This resolves
WINGs views nested inside fake_leader frames (icon chooser, message
dialogs), enabling event delivery to the correct WINGs widget.
When main_window_desc is the real WWindow (found via wWindowFor rather
than created by makeMainWindow), wApplicationDestroy must not call
wWindowDestroy on it — the window is still managed and will be destroyed
by wUnmanageWindow. Add shared_main_desc flag to track ownership.
- application.c: wApplicationCreate now tries wWindowFor(main_window)
before creating a new frameless WWindow via makeMainWindow. For
Wayland native clients where main_window == client_win, this returns
the real WWindow with its frame, title, and updated wm_class/instance.
- window.c: Disable shared_appicon for Wayland native clients (no
client_leader or group_id). The shared_appicon logic replaces
main_window with a fake group leader ID, which breaks the
wWindowFor lookup and produces a frameless duplicate WWindow.
Fixes the kill dialog showing "application" instead of the window title
for Wayland clients.
For Wayland clients, wm_instance is the window title (often long and
non-descriptive for identification) while wm_class is the app_id which
is the application identifier. Prefer wm_class for the kill confirmation
dialog, falling back to basename(wm_instance) then "application".
- findMenu(): add icon_menu to the walk list so the appicon right-click
menu responds to pointer motion during its modal drag loop.
- dragScrollMenuCallback: remove the scrollable_menus gate so menus
scroll at screen edges during drag-select regardless of the
scrollable_menus preference (that preference controls the non-modal
scroll path in handleMotionNotify which does not run during the
menu modal loop).
view_surface_at() was double-subtracting the frame_rel offset. Since
v->x/v->y already represents the client content position (frame origin
+ frame_rel), the surface-local coordinates are simply px - v->x. The
bounds check now correctly tests against 0..width/height.
Call wApplicationDestroy after wUnmanageWindow in the XWayland unmap
handler, matching the XDG and X11 handleDestroyNotify paths. Fixes
XWayland appicons persisting after the application closes.
- wl_pointer_focus.c: In view_surface_at(), check frame bounds for
XWayland views before returning the surface. When pointer is over
frame decorations (titlebar, buttons, resizebar), continue the loop
so the frame_buf handles the event. Fixes titlebar buttons (close,
iconify, shade) not responding for XWayland applications.
- wl_xwayland.c: Set left_ptr cursor on the XWayland root window at
startup via XDefineCursor. Fixes the default X cursor (big X) showing
for X11 applications that do not set their own cursor.
Enable the full appicon drag-to-dock/clip workflow for native Wayland
clients:
- window.c: Set main_window = client_win for Wayland clients that lack
client_leader and window_group, so wApplicationCreate runs and
produces a WAppIcon.
- wl_xdg.c: Call wApplicationDestroy after wUnmanageWindow on toplevel
unmap, mirroring the X11 handleDestroyNotify path. Fixes appicons
persisting after app close.
- wl_event.c: Commit the wlroots scene in wl_event_flush so
slide_windows animation renders intermediate frames.
- backend.h, x11_backend.c, wl_icon.c, superfluous.c: Add
create_rimage_from_drawable vtable method so MakeGhostIcon can read
frame_buf pixels on Wayland for the dock shadow overlay.
- wl_icon.c, wl_stubs.c: Implement wl_icon_update_pixmap with
shadowed (dimmed) overlay for attracted icons.
- wl_dock.c: Disable the placeholder shm_surface dock panel now that
the real wmaker dock framework operates via frame_bufs.
Remove duplicate W_ViewSceneNodeSetEnabledFn call, fix malformed debug code.
wl_unmap now logs cleanup diagnostics once. wl_view_scene_node_set_enabled
logs proxy ID lookup, match result, and no-match case properly.
The stale popup content visible under the main window after close comes from
the wl_redisplay composite of the popup into the parent backing (rootView).
Even though rootView is not committed to any wl_surface, the popup surface
itself retains its last committed buffer. Disabling the scene node is
insufficient for completely eliminating visual artifacts.
Fix: add wl_client_toplevel_recycle which destroys the xdg_toplevel,
xdg_surface, wl_surface, and SHM buffer but preserves the WLClientToplevel
struct and its WINGs window ID mapping. On unmap (wl_unmap), call recycle
for topLevel popups. On remap (wl_map), call wl_client_toplevel_remap which
recreates all Wayland protocol objects from scratch, triggering a fresh
configure cycle. This ensures no stale buffer or state persists between
open/close cycles.
The function only handled wl_frame_buf entries. WINGs client popup menus have
their own xdg_toplevel surface with a scene_node but no wl_frame_buf. Their
WINGs view window IDs (0x20000000+) differ from compositor view IDs
(0x10000000+), so wl_find_view_by_id could not find them.
Fix: add wlc_top_get_surface_id() in wclient_wl.c which returns the
libwayland-client proxy ID for the wl_surface. In
wl_view_scene_node_set_enabled, use this ID to iterate the compositor
toplevel_list and find the matching wlr_surface resource by object ID.
Then enable/disable the view scene_node directly.
When a WINGs client popup is unmapped (popDownMenu), the scene node is
disabled via W_ViewSceneNodeSetEnabledFn. But for WINGs client toplevels
(which have their own wl_surface + xdg_toplevel via libwayland-client),
the surface still holds its last committed buffer. Disabling the scene
node is not enough - the compositor still sees the surface as mapped.
Fix: add wl_client_toplevel_unmap which attaches NULL to the wl_surface
and commits, properly unmapping it from the compositor. Wire through
W_WLClientUnmapFn function pointer in wview_wl.c, called from wl_unmap
for topLevel views.
The function only searched for wl_frame_buf entries to enable/disable
their scene nodes. WINGs client popup menus have their own xdg_toplevel
surface with a scene_node but no wl_frame_buf. On unmap, the scene node
was never disabled, so the popup content remained rendered underneath
other windows.
Fix: fall through to wl_find_view_by_id when no frame_buf is found,
and operate on the wl_toplevel_view->scene_node instead.
The WINGs view backend wl_pointer_grab was a no-op, meaning the
press-drag-release sequence for popup menus had no effect on compositor
state. On X11 this would call XGrabPointer to redirect events to the
menu window; the equivalent on Wayland is to activate the compositor
wl_pointer_grab which sets wl_state.grab_type and suppresses unwanted
cursor resets and axis leaks during the interactive drag.
Implementation: add function pointers W_WLPointerGrabFn and
W_WLPointerUngrabFn in wview_wl.c, initialized to NULL. The compositor
wires them to wl_pointer_grab / wl_pointer_ungrab at startup.
The WINGs view backend now delegates to the compositor instead of
silently returning.
When a window is shaded (rolled up to titlebar only), the client surface
is hidden but view_surface_at would still return it for points over the
frame decorations. This caused two symptoms:
1. Pointer focus stayed on the client surface, showing I-beam cursor
instead of default arrow over the titlebar.
2. Button events routed to the client surface instead of titlebar,
preventing double-click-to-unshade from working.
Fix: after matching a toplevel view via scene graph, check whether the
associated WWindow has flags.shaded set and skip it if so.
When wl_window_resize frees the old pixman image and creates a new one,
it must call W_RegisterBacking to update the backing store. Otherwise
W_GetViewBacking returns the freed old image pointer, causing a crash
when WMDrawString (via wl_font_resolve_drawable) tries to draw into
the stale backing. This manifests on workspace name badge display
in direct render mode.
When handle_pointer_button finds a client surface at the pointer (_surf && _tv),
it searches frame_list for overlapping WINGs frame_bufs. Previously it used
any WINGs fb found, including stale entries with bogus IDs (e.g. 0x1).
Now it validates the WINGs fb via context_find() before using it as the
event window. If validation fails, the event routes to _tv->id.
The seat keyboard may be the XWayland virtual keyboard when a client
has focus, which carries no modifier state. Reading
seat->keyboard_state.keyboard->modifiers.depressed for button events
then yields 0 even when the user holds Alt, so frameMouseDown's
MOD_MASK check always fails and Alt+drag never starts.
Add current_mods to wl_compositor_state. Update it from the real
keyboard in handle_keyboard_modifiers, which fires on every modifier
change from the physical device regardless of seat focus. Use
wl_state.current_mods in handle_pointer_button to populate
u.button.state and to gate the client-forwarding suppression.
The pointer_grab call for Alt+drag (move/resize via MOD_MASK on client
surface) was passing owner_events=0. wl_pointer_grab only sets
grab_type=3 and clears seat pointer focus when owner_events is True;
with 0 the grab returned success but left no grab state, so motion
events continued flowing to the client instead of the WM drag loop.
Pass 1 (True) to match the calls in resizebarMouseDown and
titlebarMouseDown, which work correctly.
When the WM modifier key (Alt by default, configurable via ModifierKey)
is held during a button press over a client surface, do not forward the
event to the client via wlr_seat_pointer_notify_button. The event has
already been enqueued for the WM policy layer via W_WL_EnqueueEvent;
frameMouseDown will call wMouseMoveWindow (LMB) or wMouseResizeWindow
(RMB) as appropriate. Without this suppression the client application
receives the Alt+click and may act on it instead of the WM.
Three related fixes for the Wayland backend:
wl_handlers.c: populate u.button.state with keyboard modifiers
Button events were built with state=0 after memset, so all modifier-
dependent logic in window.c (resizebarMouseDown, frameMouseDown,
titlebarMouseDown) received no modifier information. Read the current
depressed modifier mask from the seat keyboard and copy it directly --
wlroots WLR_MODIFIER_* bits match the WM_MOD_* layout exactly.
wl_framebuf.c: fix frame_buf_hit to resolve child sub-windows
frame_buf_at() uses wlr_scene_node_at() which skips frame_buf children
whose scene_buf has no committed buffer (resizebar, titlebar pixels are
composited into the parent frame buffer). The hit always resolved to
the top-level frame, so events were dispatched to frameMouseDown instead
of resizebarMouseDown, and resize never started. After frame_buf_at
returns a top-level frame, do a coordinate-based child search and return
the smallest (most specific) child that contains the pointer -- the same
strategy frame_buf_button_at uses for buttons.
wl_events.c: fix wl_coords_translate to return frame-relative coords
The stub was a pass-through returning root-relative coordinates unchanged.
wMouseResizeWindow calls coords_translate(root, frame->core->window, ...)
to get frame-relative click coordinates for getResizeDirection(). Look up
the dst window in the frame_buf list and subtract its absolute position.
Three interrelated bugs caused clicks to land in the wrong place when
the compositor spanned multiple outputs (e.g. two 1920x1080 monitors
side by side in nested Wayland mode):
1. real_pointer_update_global() added lo->x to coordinates that were
already in layout space from wlr_cursor_absolute_to_layout_coords,
double-counting the output offset. It also omitted lo->y entirely,
breaking vertical monitor layouts. Fix: read position from
wlr_cursor->x/y which is always authoritative layout-space.
2. real_pointer_handle_motion() accumulated ev->delta into local_x/y
then set pointer_x/y, after which handle_pointer_motion() added
the same delta again -- doubling every relative motion. Fix: let
handle_pointer_motion() be the sole authority; use wlr_cursor_move()
which respects output layout geometry.
3. Pointer devices from nested Wayland outputs (WL-1, WL-2) were never
registered with wlr_cursor via wlr_cursor_attach_input_device() or
mapped to their output via wlr_cursor_map_input_to_output(). Without
this mapping, wlr_cursor_absolute_to_layout_coords treated the 0..1
range as spanning the entire layout (0..3840) instead of the
device's specific output (e.g. 1920..3840 for WL-2). A previous
workaround disabled absolute motion entirely for nested multi-output,
which left only relative deltas that had no concept of which host
window the mouse was in. Fix: register devices with wlr_cursor and
map them to their outputs; remove the early-return.
All pointer paths now follow the same pattern: mutate position via
wlr_cursor_move()/wlr_cursor_warp(), then read back cursor->x/y into
wl_state.pointer_x/y. Manual bounding-box clamping is retained only
for the no-cursor fallback (headless/test mode).
lkn
Levi Neely