Cascading windows

[bruno-rino]

What is the problem or limitation you are having?

When an app opens multiple windows, one has to specify a position on the screen where the window will appear. Otherwise windows will overlap each other at position=(100, 100)

This affects particularly DocumentApps, where it is natural to open several documents.

Describe the solution you'd like

I'd like to see windows cascade, like e.g. macOS TextEdit or Windows Notepad do: the new window positions shifts slightly from the position of the previous window, so that ideally at least both titlebars are visible.

The simplest API would be that if no position is provided to the Window, they should cascade.

Describe alternatives you've considered

I can imagine implementations where details vary:

• which is the previous window? The last opened window, or the currently focused window?
• which position of the previous window should be taken into account? The position assigned when creating the window (by this cascade algorithm), or the current position?
• what's the position for the first window?

And those details even vary withing macOS native apps:

• TextEdit uses the position its algorithm assigned to the last opened window (probably using this API)
• Safari uses the current position of the currently focused window

I would favor Safari's algorithm, but I'm not picky. I'd just like my windows not to hide each other.

Additional context

No response

[freakboy3742]

Agreed this is a common (and helpful) behavior that we should implement.

I don't have any particularly strong feelings about the "right" implementation, other than:

• I'd prefer using an existing platform API for the feature (such as the API you've referenced) to hand-rolling our own. This is obviously platform-dependent, though.
• I'd prefer something that doesn't require tracking internal state (such as a "last position" variable).

Edge and the File Manager on Windows seem to agree with the Safari approach you described. Terminal on GTK does the same (although it appears a little inconsistent about what the "last" window is); Firefox on GTK... has 2 mechanisms for opening a new "normal" window (plus one more for opening a private window)... and is inconsistent in it's behavior (Sigh).

On that basis, the Safari approach would seem to be the easiest to implement, and at least nominally consistent with local platform behavior.

The only qualification I'd put on your suggested API is that if the user explicitly provides a position, that position should be honoured without question. This will mean modifying the definition of the position argument so that it uses a sentinel value rather than an explicit (100,100) default - otherwise you won't be able to tell the difference between explicitly providing a default position of (100, 100), and defaulting to that position.