Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cascading windows #2023

Closed
bruno-rino opened this issue Jul 3, 2023 · 1 comment · Fixed by #2620
Closed

Cascading windows #2023

bruno-rino opened this issue Jul 3, 2023 · 1 comment · Fixed by #2620
Labels
enhancement New features, or improvements to existing features.

Comments

@bruno-rino
Copy link
Contributor

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

@bruno-rino bruno-rino added the enhancement New features, or improvements to existing features. label Jul 3, 2023
@freakboy3742
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New features, or improvements to existing features.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants