GNOME Bugzilla – Bug 681004
When snapped app requests new window it should also snap
Last modified: 2021-07-05 14:28:53 UTC
Scenario: - I have a Nautilus window snapped to left or right - I press Ctrl+N to create a new Nautilus window Result: - new window is created in the default position Expected: - new window should be snapped on the opposite edge of the snapped window already in place
Do we have any hint as to what window the user pressed Ctrl+N on, or if it was even the result of a user action? If Firefox is snapped to the left, and I open a Preferences dialog, it shouldn't be snapped to the right IMO.
(In reply to comment #1) > ... If Firefox is snapped to the left, and I open > a Preferences dialog, it shouldn't be snapped to the right IMO. That should probably be based on the locale - ltr or rtl.
(In reply to comment #1) > Do we have any hint as to what window the user pressed Ctrl+N on, or if it was > even the result of a user action? If Firefox is snapped to the left, and I open > a Preferences dialog, it shouldn't be snapped to the right IMO. Wouldn't a dialog have a transient hint to the parent window in this case? Anyway probably this would be better served as an opt-in behavior from the requesting application, e.g. I'm not sure this is exactly what we want for a Web browser (as web pages don't reflow horizontally most of the times) - but it makes sense for other applications than Nautilus, e.g. a text editor.
(In reply to comment #2) > (In reply to comment #1) > > ... If Firefox is snapped to the left, and I open > > a Preferences dialog, it shouldn't be snapped to the right IMO. > > That should probably be based on the locale - ltr or rtl. I didn't really mean to bring locale into this at all. It's just "the opposite snapped position to the snapped window that you have focused'
(In reply to comment #3) > Wouldn't a dialog have a transient hint to the parent window in this case? > Anyway probably this would be better served as an opt-in behavior from the > requesting application Sigh, yet-another-opt-in property. I consider Firefox not setting a dialog type hint on a preference dialog a bug, so not sure we should give it too much weight. Conceptually I don't see much of a difference between two toplevel nautilus windows and two toplevel epiphany windows (except that I'm much less likely to use tiling for browser windows) - IMO this is very different from the hide-titlebar-when-maximized property, which only works well if the application follows certain design patterns.
(In reply to comment #5) > Sigh, yet-another-opt-in property. I consider Firefox not setting a dialog type > hint on a preference dialog a bug, so not sure we should give it too much > weight. Not quite. Gecko has a concept of a "dialog type" that they use internally. It used to set the hint, but ever since we removed the close button, they stopped doing that, as several of their dialogs don't have explicit in-UI close buttons.
(In reply to comment #6) > It used to set the hint, but ever since we removed the close button, they > stopped doing that, as several of their dialogs don't have explicit in-UI > close buttons. Sure, but I don't think we should base UI decisions on Mozilla's reluctance to add a button to their about dialog ...
Clearly, we wouldn't do this for windows that are transient for another window, right ? My guess at workable heuristics would be: - If a new toplevel window is opened - and it is the same application as the currently active window - and the currently active window is half-tiled - and there's no other window in the other half-tile slot - then tile the new window in the empty slot next to it
Wonder if it would also be good to add: - If the window is maximized and a new toplevel window is created for the same app - make each window half-tiled. - If the screen is larger than than rules set in bug 651075 then don't use slots but snap new window to the right edge of the current window.
(In reply to comment #9) > - If the screen is larger than than rules set in bug 651075 then don't use > slots but snap new window to the right edge of the current window. Snap to right edge? So that they're in sync, and if I drag one, I drag the other? Eesh. Do we want to have a generic window group-snapping mechanism?
Snap meaning position not lock together.
So, this is all about replacing side-by-side tiling in nautilus. Eventually, it would be nice if we could just group two windows together, without them being necessarily half-maximized. But for 3.8, I would be very happy if we could make two things work: 1) (as described initially) if a windows is half-maximized, and the other slot is free, and the same app opens another toplevel window (not dialog), put it in the other slot (provided size restrictions, etc, allow that). This would cover Ctrl-N in nautilus. 2) an application should be able to explicitly request tiling two windows side-by-side. Ideally, the two windows don't have to be mapped (and would be mapped as a side effect). This would cover F3 in nautilus. On a laptop screen, this will be good enough to bring back the side-by-side tiling we had. On a huge monitor, forcing the windows to be half-maximized will be less than ideal, and real grouping would be nicer. But that can come later...
If this is indeed "all about replacing side-by-side tiling in nautilus", it fails miserably. Again, F3 in Nautilus was not (only) a visual concept (and even there this solution falls behind). It was semantic - the two sides had an inherent connection.
Created attachment 238017 [details] [review] window: Auto-tile some windows When mapping a new toplevel window, tile it automatically if the currently focused window belongs to the same application and is either tiled or maximized. (In reply to comment #8) > Clearly, we wouldn't do this for windows that are transient for another window, > right ? > > My guess at workable heuristics would be: > > - If a new toplevel window is opened > - and it is the same application as the currently active window > - and the currently active window is half-tiled > - and there's no other window in the other half-tile slot > - then tile the new window in the empty slot next to it (In reply to comment #9) > Wonder if it would also be good to add: > > - If the window is maximized and a new toplevel window is created for the same > app - make each window half-tiled. Here's an initial shot at implementing the behavior outlined in the two comments above. It works generally OK, with the exception of Firefox (which sets a NORMAL type hint for all windows, including dialogs). Adding an additional requirement of matching window roles fixes the Firefox case for me, but breaks other applications, so this is not included in the patch. Any other ideas how to deal with applications that don't use type hints correctly?
(In reply to comment #14) > > Here's an initial shot at implementing the behavior outlined in the two > comments above. It works generally OK, with the exception of Firefox (which > sets a NORMAL type hint for all windows, including dialogs). Adding an > additional requirement of matching window roles fixes the Firefox case for me, > but breaks other applications, so this is not included in the patch. Any other > ideas how to deal with applications that don't use type hints correctly? No but this is broken for another case as well ... when a website opens a small popup you don't really want to have it end up half maxmized and having the main window being resized as well. I'd say we should just drop the maximize bit ...
(In reply to comment #15) > No but this is broken for another case as well ... when a website opens a small > popup you don't really want to have it end up half maxmized and having the main > window being resized as well. > > I'd say we should just drop the maximize bit ... Yeah, sounds worth a try ... (I found another offender - Evolution :-( )
Review of attachment 238017 [details] [review]: Marking needs-work to get it off the list.
*** Bug 712653 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.