GNOME Bugzilla – Bug 123838
Right, left, bottom onscreen onstraints wrong
Last modified: 2004-12-22 21:47:04 UTC
the resize constraints code for right, left, and bottom is broken if you think about it. The code calls get_outermost_onscreen_position, which returns values for the outermost points that can be occupied by the upper left corner of the window and have the window still be visible onscreen. However, these functions, which control the ability to resize the right, left, and bottom edges use this value as the outermost position for _those_ edges, which is simply wrong. In reality there is no way that resizing these edges could cause the onscreen constraint to be violated; as such these functions should all be no-ops. A patch will be attached that fixes a large number of constraints bugs reported here.
Created attachment 20461 [details] [review] fix conceptual problem with onscreen resize constraints
Don't we want to constrain the left side? You shouldn't be able to move the menu button off the left. BTW Alan Cox suggested an alternate approach to constraints (yes, another one): take the proposed new rectangle as x1,y1 x2,y2; and _clip_ that rectangle to the screen area. Then clamp down to the nearest geometry-hints-permitted size. This is more like the old "is this rectangle allowed" approach, except that size/position are handled together so you may not get the bugs that caused us to move to constraints.c. It's an idea. Maybe it would turn out to have fatal problems. I believe the X region code and/or GdkRegion could be used to implement the "clip the window" approach to constraints.
we don't currently constrain the left edge of the window to keep the menu button onscreen, and I don't think that it would be a good idea. The idea of the constraints code has always been to keep the titlebar accessible so that the window can be moved back no matter what happens to it without needing to know a trick like Alt-move or keyboard move. I don't really see any pressing reason to keep the menu button visible. We might try a clipping approach, but that would lead to some very odd effects I would expect. Consider for example moving a window off the left. A clipping approach would, as you move the window over, cause the window to get smaller and smaller as it hit the leftmost position allowed. Of course, we do need a 2.4 series fix for these bugs and we certainly can't implement a completely new constraints engine for that, though I think that it may be a good idea in the long run. I propose that I commit this patch and then branch for 2.4.
although the clipping approach might be a good one for move/resize configure requests, now that I think about it. Not for user move/resize requests though.
you know something else just occurred to me: Since we're now doing resize then move, why not disable onscreen resize constraints entirely? It will always be possible to meet the onscreen constraint in the subsequent move. This means that if an application for example sets a south gravity and resizes itself off the top, the window will be pushed back down so that the titlebar is again visible. The result is that a window will never end up with a size other than what it requested, and we can retain our semantics of always maintaining the titlebar visible.
Havoc, can I commit this patch? This should definitely be in the Gnome 2.4.1 release.
Yeah, go ahead with the patch. On your other comment (remove resize constraints entirely) think of the case where the user interactively resizes the top edge and the way that was broken in 2.4.x (when you hit the top of screen the bottom edge would start to move).
committed and metacity has been branched for gnome 2.4. Not really clear on the whole versions thing. Is the Fibonacci series in configure.in relevent in some way?