Created attachment 29455 [details] [review]
proposed patch

Stores the resolution info along with other session information. This info is
used while 'placing' the windows during session restore.

Do you think scaling the windows is really right or should we just push the
windows onto the screen and force them down to max size == screen size?

IMHO, it would be better to scale the windows so that they keep the original
positions instead of cropping them. For example, if a window is placed near the
side, it will get trimmed to a narrow strip which would be ugly. The user would
expect the window to have the same height/width proportion when the resolution
is changed.

either policy should be fine here.  This is kind of a corner case anyway, and
window constraints will still be honored.  So we should probably go ahead and
commit this (assuming it still applies).

I think constraining would be a lot better than scaling...

surely at least, scaling the position makes sense ?

Michael: Isn't that what constraints (must be moved so that it's onscreen; if
too big it should be shrunk unless it's below the windows minimum size hint)
effectively do?

I guess; of course, going from small->large would also be helped by a
proportional  position.

consider: "I always keep my GAIM on the RHS of the screen & my xchat on the
left" or "I like to have the FooWindow at the bottom" type scenarios.

If you store a proportional position - then with the same (administrator
configured?) setting you can achieve that effect on ~all your desktops - and
better, as you log-out it's likely to retain that proportional position.
Otherwise at least on some transition edge [ unless it's positioned to the
top/left or whatever ] you get movement & sub-optimal positioning.

Of course - storing a resolution sucks too ;-) an x_prop="0.5" or somesuch would
be better.

Just my ignorant 2cents :-)

Avoiding offscreen windows would make sense to me. Basically what makes sense to
me is that if the window is entirely onscreen with the new resolution, leave it
alone, otherwise push it onscreen via some combination of move/resize. By
"onscreen" I mean the whole window, not just the titlebar.

The make-sure-window-is-onscreen aspect of this bug should be fixed by the constraints rewrite in 2.13.x.  I'll leave open for the position-scaling issue mentioned by Michael but drop the severity to enhancement.

Well, while we're stuck thinking about whether we want scaling, a couple comments on the patch:

There are spacing issues: indentation is not always consistent with the rest of the code and often uses tabs when it shouldn't.

Patches should be created with the -p flag (as well as the -u flag).

I don't like adding an additional meta_window_move_resize_internal() call.  Rather the code should make sure that if both info->geometry_set and info->resolution_set then there's still only one call.

The hardcoding of NorthWestGravity for the call to meta_window_move_resize_internal() is not good; should use the window's gravity instead.  Also, using flags=META_DO_GRAVITY_ADJUST is not right; it's a move and resize operation as well (though perhaps this patch was before the constraints rewrite which involved changes to meta_window_move_resize_internal arguments?)

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all
old feature requests in Bugzilla which have not seen updates for many years.

If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be implemented.