NULL-buffer unmap triggers a wlroots xdg_surface unmap, which requires a
configure/ack cycle before the next buffer attach. This creates a race
window where the popup reopen cannot commit its real buffer yet, causing
the click to hit the main window instead of the popup.
Fix: replace the popup buffer with a 1x1 transparent ARGB buffer instead
of attaching NULL. This hides the popup visually (the tiny buffer is
invisible) without unmapping the xdg_surface. The surface stays configured
and alive, so the next popup open can commit a real buffer immediately
without waiting for a configure event.
Also: always call resizeMenu() in popUpMenu to ensure the backing buffer
is recreated at the correct dimensions after the 1x1 replacement.
In WINGs client mode (e.g. WPrefs), W_ViewSceneNodeSetEnabledFn was never
set because the compositor-side wl_backend.c does not run in the client
process. When popup close calls wl_unmap, the function pointer was NULL,
so the scene node was never disabled and the popup remained visible.
Fix: during W_WLClientInit, if W_ViewSceneNodeSetEnabledFn is still NULL
(unset by compositor), set it to wl_client_scene_node_set_enabled which
calls recycle (destroy xdg_toplevel + wl_surface) on disable and remap
(recreate from scratch) on enable. This ensures the client-side popup
lifecycle correctly removes and recreates the surface, eliminating stale
pixels without depending on compositor-side function pointers.
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.
When a topLevel popup is unmapped, wl_redisplay(view-parent) clears stale popup pixels from the parent backing. But for rootView (common parent), the commit at the end of wl_redisplay is a no-op because rootView has no WLClientToplevel. The cleared backing was never pushed to any surface. Fix: iterate parent child list and force-commit every topLevel sibling, pushing the cleared backing to their wl_buffers.
When a WINGs popup is unmapped (popDownMenu) and remapped (popUpMenu),
the scene node is re-enabled via W_ViewSceneNodeSetEnabledFn, but its
Z-order position stays at its original insertion point. Other surfaces
mapped while the popup was disabled may now sit above it, making the
popup invisible when it reappears.
handle_toplevel_map (which calls wmaker_popup_apply to raise the
popup) only fires on the initial xdg_surface map event, not on
scene-node re-enable. Fix by calling W_WLClientPopupSetPosition on
every topLevel popup map, which triggers wmaker_popup_v1_set_position
→ wmaker_popup_apply → wlr_scene_node_raise_to_top.
When the pointer leaves the main button view to enter the popup surface,
the WME_LEAVE event fires for bPtr->view (which shares the same
handleActionEvents handler). This unconditionally cleared insideMenu=0
and highlightedItem=-1, causing the subsequent button release to fail
the selection check and not fire the action.
Fix: guard the leave handler with event->window == bPtr->menuView->window
so that clearing only happens when the pointer actually leaves the menu
view, not when it just leaves the main button on its way to the popup.
pointer_handle_enter always sent WME_ENTER to the toplevel root view
with _view_target=NULL, so child views (e.g. menuView) never received
proper WME_ENTER with correct local coordinates when the pointer entered
the popup surface during a held drag.
Fix: hit-test against the newly-focused toplevel on enter, find the
deepest child at the pointer position, and deliver WME_ENTER to that
child view with proper local coordinates and _view_target set.
Also fix pointer_handle_leave to deliver WME_LEAVE to the deepest
child (via wlc_ptr_child_focus) instead of the toplevel root view,
matching the enter side.
When a popup menu is opened during a button-held drag, the compositor
changes pointer focus to the popup surface as the pointer enters it.
But pointer_handle_motion always delivered events to the originally
grabbed view (wlc_ptr_grab), never hit-testing inside the popup.
This meant wpopupbutton.c received motion events targeted at the
main button view with coordinates relative to that view, not the menu.
Fix: in both pointer_handle_motion and pointer_handle_button (release),
check whether the grab target is within the currently focused toplevel.
If not (the pointer entered a different surface), use wlc_hit_test
against wlc_ptr_focused to find the correct child view with proper
local coordinates.
Also enable enter/leave synthesis during grabs when target changes,
so child views receive proper WME_ENTER/WME_LEAVE as the pointer
moves between them across the cross-surface boundary.
When the popup opens via ButtonPress on the main button, compute the
highlighted item from the pointer position relative to the menu view,
matching upstream WINGs semantics. Previously highlightedItem was set
to selectedItemIndex, which might be -1 (no prior selection), causing
the popup to open with no visible highlight until the first motion event.
The fix uses event->u.button.y_root - menuView->pos.y divided by item
height to determine which item the pointer is over when the menu appears.
This item is painted as highlighted immediately on open.
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.
The non-highlight path in paintMenuEntry only filled the row with gray
and returned early, erasing the item text, relief border, and indicator
pixmap. On Wayland this was immediately visible because the cascade+commit
on fill_rect commits every draw operation to the wl_surface.
Fix: after filling the gray background, redraw the relief border, the
item text (in black or darkGray depending on enabled state), and the
indicator pixmap for the selected item — matching what the highlight path
and makeMenuPixmap do.
Bug 1: Clicks on menu items did not select the correct item.
The WME_BUTTON_PRESS handler always called popUpMenu() which re-mapped
the already-open menu and reset highlightedItem to selectedItemIndex,
ignoring the click position. Since no motion event follows a
click-without-drag, the highlight was never corrected.
Fix: distinguish menuView vs main button events via event->window.
For menuView clicks, compute highlightedItem from click.y directly
without re-opening the menu.
Bug 2: Second popup open showed a blank gray box.
wl_unmap disabled the compositor scene node via W_ViewSceneNodeSetEnabledFn
but wl_map never re-enabled it. On re-map, the buffer was committed
to the wl_surface but the scene node stayed disabled.
Fix: re-enable scene node in wl_map before redisplay.
Reorder popUpMenu to:
1. Resize menuView before map (correct backing dimensions)
2. W_MapView first (wl_map calls wl_redisplay which fills background
and dispatches WME_EXPOSE — the old redisplay() before map was a
no-op on Wayland because wl_redisplay returns early when !mapped)
3. Copy makeMenuPixmap() output into menuView->window backing as a
safety net, ensuring the buffer has complete menu content
independent of expose-timing correctness
4. paintMenuEntry for initial highlighted item
This ensures the first visible popup buffer has all menu items
rendered regardless of the order in which the Wayland configure
and commit events arrive.
Three related fixes for WINGs popup menus on Wayland:
1. wl_client_toplevel_resize: update pending_w/h after resize
(wclient_wl.c:545-546). Without this, the configure handler sees
stale pending dimensions and creates a wrong-sized buffer,
discarding the one containing the menu text.
2. Export wl_redisplay_depth (wview_wl.c:288) so render and font
backends can detect when they are called from within a full
redisplay cycle vs. from an event handler.
3. Add cascade+commit to render_wl_fill_rect (wrender_wl.c:162-183)
and wl_draw_string (wfont_wl.c:183-208) when not inside a
redisplay cycle. This makes motion-driven highlight changes
(text color, background fill) immediately visible by compositing
up the view tree and committing the toplevel wl_surface.
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.
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.
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.
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.
lkn
Window Maker
Ollie
Ollie