Created attachment 272388 [details] [review]
window: Replace the user_rect with the unconstrained_rect

Realistically, the user rect contains the unconstrained window
rectangle coordinates that we want to be displaying, in case
something in the constraints change.

Rename it to the "unconstrained_rect", and change the code to always
save it, regardless of current state.

When metacity was originally being built, the purpose of the user
rect was a lot less clear. The code only saved it on user actions,
with various other calls to save_user_window_placement() and a force
mechanism sprinkled in to avoid windows being snapped back to odd
places when constraints changed.

This could lead to odd bugs. For instance, if the user uses some
extension which automatically tiles windows and didn't pass
user_action=TRUE, and then the struts changed, the window would be
placed back at the last place a user moved it to, rather than where
the window was tiled to.

The META_IS_USER_ACTION flag is still used in the constraints code
to determine whether we should allow shoving windows offscreen, so
we can't remove it completely, but we should think about splitting
out the constrainment policies it commands for a bit more
fine-grained control.

Review of attachment 272388 [details] [review]:

This seemed to only raise more questions when we discussed it on IRC. There's obviously lots of existing bugs in master, especially with CSD. If you have a regular window partially offscreen, and then start resizing it, it will stay in place offscreen and resize just fine. If you have a CSD window, however, it will pop back onscreen. This is because the frame extents "change" during resizing, so we queue a move_resize which doesn't pass user_op to move_resize_internal.

There's also a bug in that it seems invisible borders are taken into account in this as well, so somebody's missing a frame_rect_to_client_rect somewhere.

I think the "correct" fix here is to save whether the placement was last done by the user or the compositor, and use that information inside meta_window_move_resize_now.

And in that sense, I wonder if it even makes sense to have the unconstrained_rect case anymore. Constraints changing is fairly rare in GNOME anyway, and perhaps it doesn't make sense to optimize for this case. The user just won't have the window resize when constraints change, and I feel that's fairly OK.

Attachment 272388 [details] pushed as 2c0ad5b - window: Replace the user_rect with the unconstrained_rect


I'm going to push this. It shouldn't change much behavior, and it's a significant cleanup getting us ready for window geometry. If we want to revisit this, we should probably develop a new user policy and think about how to implement that.