After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 681004 - When snapped app requests new window it should also snap
When snapped app requests new window it should also snap
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: window-management
3.24.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 712653 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-08-01 16:56 UTC by Cosimo Cecchi
Modified: 2021-07-05 14:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
window: Auto-tile some windows (2.06 KB, patch)
2013-03-04 16:50 UTC, Florian Müllner
needs-work Details | Review

Description Cosimo Cecchi 2012-08-01 16:56:04 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
Comment 1 Jasper St. Pierre (not reading bugmail) 2012-08-01 17:04:00 UTC
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.
Comment 2 Allan Day 2012-08-01 17:49:06 UTC
(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.
Comment 3 Cosimo Cecchi 2012-08-01 17:53:34 UTC
(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.
Comment 4 Jasper St. Pierre (not reading bugmail) 2012-08-01 18:08:19 UTC
(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'
Comment 5 Florian Müllner 2012-08-01 21:38:03 UTC
(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.
Comment 6 Jasper St. Pierre (not reading bugmail) 2012-08-01 21:41:03 UTC
(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.
Comment 7 Florian Müllner 2012-08-01 21:45:43 UTC
(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 ...
Comment 8 Matthias Clasen 2012-08-28 13:20:26 UTC
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
Comment 9 William Jon McCann 2012-08-28 14:11:49 UTC
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.
Comment 10 Jasper St. Pierre (not reading bugmail) 2012-08-31 17:09:03 UTC
(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?
Comment 11 William Jon McCann 2012-08-31 17:35:21 UTC
Snap meaning position not lock together.
Comment 12 Matthias Clasen 2013-02-06 17:51:54 UTC
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...
Comment 13 Holger Berndt 2013-02-06 20:39:56 UTC
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.
Comment 14 Florian Müllner 2013-03-04 16:50:56 UTC
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?
Comment 15 drago01 2013-03-05 12:52:03 UTC
(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 ...
Comment 16 Florian Müllner 2013-03-05 20:53:47 UTC
(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 :-( )
Comment 17 drago01 2013-03-06 21:38:39 UTC
Review of attachment 238017 [details] [review]:

Marking needs-work to get it off the list.
Comment 18 António Fernandes 2013-11-20 11:17:42 UTC
*** Bug 712653 has been marked as a duplicate of this bug. ***
Comment 19 GNOME Infrastructure Team 2021-07-05 14:28:53 UTC
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.