[Enhancement] Canvas ideas

[samukhin]

Hello! I've collected some ideas for possible improvements:

• Looped canvas (2147483647 + 1 = 0), this will bring camera, windows and canvas to a single i32 instead of i32 and f64. At the moment, if you set the window position to 2147483647:2147483647, the window just stands and rests.
• Zoom in and out, and display the same magnification as in Cosmic
• Make an interface for managing and viewing window positions by kind, both in TouchView and FVWM.
• And if it comes down to it, a simple custom text indicator would be fine. For example, I'd like to see the battery charge without any waybars.

[malbiruk]

Thanks for the ideas!

loopable canvas, i32 instead of f64

The practical coordinate range is ~4 billion pixels in each direction, which is unreachable in normal use. Window rules that place windows at extreme coordinates like 2147483647 is more of a validation edge case. Making the canvas loopable would add significant complexity to coordinate math without a clear UX benefit, since the canvas won't become more infinite because looping breaks "infinite" illusion same way as unable to move window further. Keeping it as-is for now.

zoom in and out, and display the same magnification as in Cosmic

Not showing a zoom indicator directly, but the current zoom level is already exposed in $XDG_RUNTIME_DIR/driftwm/state so any external tool can display it. I'm planning to support zoom > 1.0 with a state machine where 1.0 acts as a boundary -- a single gesture can't cross it, you'll need to release and start a new gesture to go past (in either direction).

Make an interface for managing and viewing window positions by kind, both in TouchView and FVWM

And if it comes down to it, a simple custom text indicator would be fine. For example, I'd like to see the battery charge without any waybars.

In my philosophy the compositor stays a clean empty canvas, but is pluggable. It doesn't render text anywhere by design. Instead it provides building blocks: window rules with widget = true for canvas-pinned apps, layer-shell support, and a state file ($XDG_RUNTIME_DIR/driftwm/state) exposing viewport position, zoom, and window info (now only app ids though, but I can expose window positions and sizes too). A pinned-to-screen window rule (always-on-top, unaffected by zoom) is planned. So a minimap, battery indicator, or zoom display can all be built as external tools reading the state file. The compositor just needs to expose enough data, not render it itself.

[samukhin]

In my philosophy, the composer remains a clean, empty canvas.

And that's great, less visual clutter! But I had to suggest it. :)

[malbiruk]

I'll close this issue once I expand state file and implement magnifying zoom then

[samukhin]

I was thinking...

Maybe it would be possible to at least add a "visible border" to the canvas? And it would also be nice to be able to customize the canvas size. Let's say I want 10000x10000 with a border that ensures all windows are within it. This would make it easy to "see everything" even at maximum zoom.

[malbiruk]

I think I'm going to pass on that. You can see everything with "zoom-to-fit" (overview) action at any time, why is a border needed for that?

[samukhin]

If you position windows too far apart, which i32 allows, then at maximum zoom, you can't see anything.
Regarding the border... Let's say a user wants to arrange windows to a clear boundary so they don't slide away. They teleport to 2147483647:2147483647. And they arrange everything carefully, knowing full well that nothing will slide away. And they see the actual border; they don't have to guess.
And if you add canvas size, you have even more control; at least you'll be able to see each window precisely!

[samukhin]

Subjectively, this could add more "polished" to the project. For example, currently, if a window is placed as high as possible, it simply disappears (visually, receding into an invisible area). Elaborating on the borders and allowing them to be customized would definitely improve this.

[samukhin]

This is roughly how the border with multiple monitors is implemented.

P.S. Yes, I compiled this for Ubuntu 22.04 and even for Debian 9 :)))