Canvas Physics: Windows as Physical Objects

[wwmaxik]

Summary

Add optional physics simulation where windows behave as physical objects with repulsion, friction, and collision detection.

Motivation

When opening multiple windows in the same location, they currently overlap completely. With physics enabled, windows would automatically "push away" from each other and settle into an organic layout without manual positioning.

This creates a unique UX that doesn't exist in any other window manager — a middle ground between manual floating and rigid tiling.

Proposed Implementation

Configuration

Add a new [physics] section to config.toml:

[physics]
enabled = false              # opt-in, disabled by default
repulsion_strength = 50.0    # force between nearby windows
friction = 0.95              # movement damping (0.9=snappy, 0.98=floaty)
collision = true             # prevent window overlap
mass_based = true            # larger windows = more mass = harder to push
repulsion_distance = 200.0   # distance threshold in canvas pixels

Behavior

• Windows repel each other when closer than repulsion_distance
• Force decreases with distance (inverse square law or exponential falloff)
• User can still drag windows manually — physics applies when released
• Physics pauses during active drags/resizes
• Keybinding to toggle physics on/off (e.g., mod+p)

Use Cases

1. Rapid prototyping layouts: Open 5 terminals → they auto-arrange in a circle
2. Organic workspace: Windows naturally cluster by usage without rigid tiling
3. Demo/presentation mode: Windows gracefully avoid each other when moving viewport
4. Accessibility: Users who struggle with precise positioning get automatic spacing

Technical Considerations

• Run physics simulation in tick_all_animations() (udev) or animation timer (winit)
• Apply forces as velocity deltas, integrate position each frame
• Use spatial hashing or quadtree for efficient collision detection (O(n log n) instead of O(n²))
• Clamp velocities to prevent "explosion" bugs
• Add damping to prevent infinite oscillation

Visual Feedback

• Optional: show repulsion "field" lines when mod is held (debug visualization)
• Smooth easing when windows settle into position

Prior Art

• Compiz "Wobbly Windows": physics for window drag (inspiration for feel)
• Blender node editor: nodes repel when auto-arranged
• Figma auto-layout: similar concept but for UI elements

Open Questions

• Should layer-shell surfaces (waybar, etc.) participate in physics?
• Should widgets be "anchored" (infinite mass)?
• Interaction with window snapping — disable snap when physics is active?

Implementation Roadmap

1. Add basic repulsion between two windows (proof of concept)
2. Extend to all windows with spatial optimization
3. Add collision detection
4. Tune parameters for good "feel"
5. Add config options and keybindings
6. Write tests for physics edge cases (zero-size windows, etc.)

I'm happy to help test this if there's interest!

[malbiruk]

Thanks for the detailed proposal! I've been thinking about the same problem -- windows shouldn't overlap, and arranging them manually gets tedious.

I thought about adding physics too, but it would add a lot of complexity, make interacting with compositor much less predictable, tuning physics is another thing which needs to be done right, and physics layer introduces idle cost.

I'm currently solving this issue with snap-adjacency groups. Snap is deterministic and predictable. On top of that I'm currently addding on-demand calculation of snapped windows graph.

The https://github.com/malbiruk/driftwm/tree/window-groups branch has the first two working:

1. Move group -- drag a snapped window and its neighbors follow. Closes Bulk window movement #5
2. Resize propagation -- resize inside a cluster, adjacent windows shift to keep gaps. No overlap.
3. Zoom-to-fit group -- center viewport on the focused window's cluster.
4. Spawn in cluster (opt-in, default off) -- new window auto-places at the nearest free edge of the focused window's cluster. Addresses Open new windows in their own space #31

Physics could complement this well in the future as the engine behind placement and resize propagation within groups. Right now those are hand-rolled constraint solvers. A physics settle step could replace them with something simpler and more general. The snap-adjacency group structure would stay the same, physics would just handle the "how do members rearrange" part.

Something to explore once the current foundation is solid.

[wwmaxik]

Thanks for the thoughtful reply! I completely agree that determinism and predictability should come first in a WM — snap-adjacency groups sound like a solid, pragmatic solution.

I'd love to test the window-groups branch and see how resize propagation and cluster spawning feel in daily use. If you're looking for feedback on edge cases or UX polish, happy to help.

Also really like the idea of keeping physics as a potential 'settle step' backend later — that could be a nice evolution once the foundation is stable. Keep up the great work!