1
0
Fork 0
Pure Odin windowing library.
Find a file
2026-02-05 06:34:53 -06:00
examples Implement cursor modes, shapes, key polling, and raw mouse motion 2026-02-04 21:55:17 -06:00
window Fix specifying X11 for window backend, partially fix Wayland "X to close" 2026-02-05 06:34:53 -06:00
.gitignore Implement cursor modes, shapes, key polling, and raw mouse motion 2026-02-04 21:55:17 -06:00
CLAUDE.md Phase 3: Window operations (fullscreen, maximize, decorations) 2026-02-03 19:02:34 -06:00
impl.md cleanup 2026-02-04 19:48:32 -06:00
plan.md Phase 1: Core windowing library with X11 backend 2026-02-01 07:31:16 -06:00
readme.md Phase 1: Core windowing library with X11 backend 2026-02-01 07:31:16 -06:00

Window

This project aims to be a fully cross-platform library for creating windows. We'll take the best ideas of other libaries and apply them liberally here, while maintaining Odin idioms.

GLFW — great reference for minimalism

Why its valuable

  • Very tight scope: windows, input, cursors, monitors, timing
  • Clear separation between windowing and rendering
  • Proven longevity and stability
  • Easy to reason about

Why not copy it directly

  • C-style global state + callbacks
  • Pull-based input querying (glfwGetKey) feels un-Odin
  • Callback soup doesnt map well to Odins structured control flow

What to steal from GLFW:

  • Small, opinionated surface area
  • “We dont manage your renderer” stance
  • Simple lifecycle rules

If you want something that feels like core:window, GLFW is the right size reference.4

winit — best conceptual model for Odin

Why winit maps well to Odin

  • Event-driven core
  • Explicit event loop ownership
  • Strong separation of:
    • OS events
    • User events
    • Window lifecycle
  • Backend-agnostic (X11, Wayland, Win32, Cocoa, etc.)

Even though its Rust, its design philosophy fits Odin extremely well.

  • Structured control flow
  • No hidden globals
  • Deterministic ownership
  • Backend-specific code isolated cleanly

What to adapt (not copy)

  • Central event loop as the spine
  • Typed events instead of callbacks
  • Backend modules per platform
  • Explicit control over blocking vs polling