lkn
/
windowmaker-wl
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
97 Commits 1 Branch 0 Tags 23 MiB
Commit Graph

5 Commits

Author SHA1 Message Date
Levi Neely dfac01a478 Phase 80c: add vtable slots for cross-mode rendering functions 
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.
 2026-05-13 10:24:21 +02:00
Levi Neely 9cfe322573 Phase 80b: eliminate if(dpy) guards and replace X11 calls with vtable dispatch 
- Remove all 20 'if (dpy &&' guards from policy files
- Replace XMapWindow, XUnmapWindow, XMoveWindow, XClearWindow,
  XFreePixmap, XFlush, XSync, XResizeWindow, XSetWindowBackground,
  XSetWindowBackgroundPixmap, XMoveResizeWindow, XSelectInput,
  XMapRaised, XUngrabPointer, XUngrabKeyboard, XGrabKeyboard,
  XGrabServer, XUngrabServer, XRestackWindows, XDestroyWindow,
  XReparentWindow, XAddToSaveSet, XSetWindowBorderWidth
  with vtable dispatch across all policy files
- Make wFrameWindowPaint mechanism code: X11 backend's frame_paint
  now calls it; all policy call sites dispatch through vtable
- Replace dpy feature-gating in main.c/startup.c with is_wayland

Remaining: 278 dpy refs in policy files, mostly in rendering functions
(wIconPaint, wAppIconPaint, paintEntry, drawFrame, balloon, dock,
dialog, superfluous, event) that are X11 mechanism code reachable
only through the X11 backend path.
 2026-05-13 10:21:00 +02:00
Levi Neely 9b2448dd7f WIP: Wayland backend - fix atoms, OR surface compositing, frame/window ops 
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.
 2026-05-13 07:05:22 +02:00
Levi Neely a486329b52 Wayland backend abstraction: WMBackend vtable (Phases 0–30) 
Introduce a display-system-agnostic WMBackend vtable that routes all
display operations through function pointers, making the WM policy
layer independent of X11.  The X11 implementation is preserved in
src/backend/x11/ and behaviour is unchanged.

Key structural changes
──────────────────────
• src/backend/backend_types.h — backend-neutral type definitions:
    WNativeWindow, WKeyCode, WContextKey, WBackendScreen,
    WBackendEvent (+typed fields), WNormalHints, WWMHints,
    WNETWindowType, WHeadGeometry, WClientAttributes, WClientVisual,
    WSegment, WPoint, WM_KEY_* keysym constants, WA_* atom IDs,
    WKB_GROUP*_INDEX, WCUR_NONE

• src/backend/backend.h — WMBackend vtable (~100 function-pointer
    slots) covering: frame/context lifecycle, stacking, focus, grabs,
    pointer, keyboard, overlays, properties, ICCCM, EWMH/NETWM,
    monitors, screen setup, cursors, extensions, error handlers.
    No <X11/> headers remain in this file after Phase 30.

• src/backend/x11/ — X11 backend implementation:
    x11_backend.c  full vtable; all display calls confined here
    x11_props.c    WM_NORMAL_HINTS / WM_HINTS translation
    x11_event.c    XEvent → WBackendEvent translation
    x11_monitor.c  Xinerama / RandR monitor query

Policy files cleaned
────────────────────
All 47 files in WM_POLICY_CLEAN_FILES pass check-no-x11-policy
(no direct #include <X11/> anywhere).  X11 types that still appear
in policy structs (Visual*, Colormap, Window, Atom …) arrive only
transitively via WINGs.h; the vtable boundary itself is X11-free.

Tests
─────
• tests/smoke-test.sh — full Xvfb lifecycle test (PASS)
• tests/test_geom.c   — geometry / constraint unit tests
• tests/test_x11_event.c — WBackendEvent field extraction tests

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-03-27 19:20:00 +01:00
Levi Neely fcee811b99 WindowMaker 0.96.0 upstream source 2026-03-26 15:38:49 +01:00