Open new windows in their own space

[Kyza]

My first action when opening a new window is to drag it over to the closest empty area before using it. It would be nice to have a config setting that opens new non-floating dialog windows in the closest open space to the viewport of the monitor, and moves the viewport to focus it.

[malbiruk]

Thank you for the suggestion. I want to share how I see it before deciding, because I'm not sure what option is the best to address it.

The way I use driftwm myself is: I pan the viewport to an empty area first, and then spawn a new window. New windows appear centered in the viewport, so they end up exactly where I want without the compositor doing anything special. Actually, this is the intended workflow -- it keeps everything predictable, you stay in control of window placement, and there's zero new code and additional complexity needed for it.

I also tried to think how to actually implement automatic placement, and each idea I had has problems:

• "nearest empty space" (either a canvas-wide search for nearest empty space, or a local snap near focused window) -- pretty unpredictable, the spawn position depends on surrounding layout and the viewport jump can be disorienting
• "right of focused window, stack down on collision" -- works but starts turning driftwm into a scrollable tiling WM, which isn't the direction I want to take.

That said, I don't want to dismiss this too quickly -- maybe there's a workflow I'm not seeing, or other people have thoughts on this.

Leaving it open for discussion for now.

[malbiruk]

Also I'm thinking maybe add a config option to spawn new windows at cursor position? Will it solve the problem?

The workflow would be: move the cursor to an empty space first (still you arrange all your windows -- floating WM philosophy, full freedom of window positioning and size), then press shortcut/run window from launcher.

But if after this we center viewport on new window, you'll probably need to move your cursor back to center, but it's still better than dragging a window, or in that case we can not center (you center with center-window action explicitly if you need), what do you think?

[Kyza]

With driftwm I find I love to keep a mass of windows open, and clean more rarely. So the general area of the canvas I'm in corresponds to the idea I'm working around. So if I'm working on multiple programming projects, they'll have their own groups of windows. When I open a window related to an idea I'll be in that area already.

I find that I desire to just open a window and use it as quickly as possible, more than opening and placing it exactly where I want it. With it snapping to the nearest empty spot, that eliminates having to pan over or use my mouse at all. I could simply use my keyboard to open the window and not worry about where I am or it overlapping something else I'm doing. If I truly don't like where it spawns, then I can use my mouse to move it.

As a side note, I'd actually prefer randomness and unpredictability to where they spawn, simply because it creates an aesthetic I enjoy. I personally never have issues losing windows because I create an association of where it is with where the project is.

Another side note, I dislike that with the current behavior the viewport scales down to the window if I'm zoomed out. I think there are just a bunch of different workflows driftwm can provide because of how free the canvas is, and it might benefit from a few configuration options around that.

[malbiruk]

Ok, so how do you imagine the behavior in detail?

Find a free (or mostly free if there's another window) edge of currently focused window and snap new window to it? And what to do if no free place found -- track the whole snapped cluster and move you somewhere far or allow to overlap? Or find this empty space not from currently focused window but from viewport center maybe?

Also can you elaborate on this "Another side note, I dislike that with the current behavior the viewport scales down to the window if I'm zoomed out" -- what do you mean it scales down to the window if you're zoomed out? You mean on spawning new windows?

[malbiruk]

Actually I use driftwm same way -- having these clusters of snapped windows.

A bit unrelated thing, but I'm planning to do window groups somehow #5 and I feel that the snapped clusters might be the answer. No need to create select-like tool, just track snapping state as group of windows and add new action to move window group, also i want to add resize by these snapping boundaries, and an action to zoom-to-fit current cluster / window group.

And this new feature you're proposing could align pretty well in that model -- to find empty space from focused window inside current window group and spawn window in that window group.

It's a pretty big scope though and not a single feature ofc.

[malbiruk]

Another side note, I dislike that with the current behavior the viewport scales down to the window if I'm zoomed out. I think there are just a bunch of different workflows driftwm can provide because of how free the canvas is, and it might benefit from a few configuration options around that.

check this commit on main, does it solve the problem?
f49150d

[wwmaxik]

I just proposed a solution for this in Discussion #36 - Canvas Physics!

Instead of manually finding empty space for new windows, they could automatically repel each other when they overlap. When you open multiple windows in the same spot, they would naturally "push away" and settle into an organic layout.

This would solve your use case (new windows finding space) plus work for any windows that get moved close together.

Check it out: #36

[Kyza]

Ok, so how do you imagine the behavior in detail?

Find a free (or mostly free if there's another window) edge of currently focused window and snap new window to it? And what to do if no free place found -- track the whole snapped cluster and move you somewhere far or allow to overlap? Or find this empty space not from currently focused window but from viewport center maybe?

My thought is it would locate the closest area that the window can fit in without resizing it. That'd usually be the currently focused window, but it could be somewhere farther away.

Also can you elaborate on this "Another side note, I dislike that with the current behavior the viewport scales down to the window if I'm zoomed out" -- what do you mean it scales down to the window if you're zoomed out? You mean on spawning new windows?

Another side note, I dislike that with the current behavior the viewport scales down to the window if I'm zoomed out. I think there are just a bunch of different workflows driftwm can provide because of how free the canvas is, and it might benefit from a few configuration options around that.

check this commit on main, does it solve the problem? f49150d

That commit solves it, thank you!