Re: Suggestion: Gravity and resizing from the left

[Owen Taylor <otaylor redhat com>]

Dominik Vogt <dominik.vogt@fvwm.org> writes:

> On Wed, Nov 17, 1999 at 03:30:55PM -0500, Owen Taylor wrote:
> > 
> > This is somewhat off-topic on the list, but I'm mailing
> > it here because the audience of this message is window
> > manager authors; I'll pretend that it is relevant by
> > saying that if people agree with my suggestion it could
> > be added to the spec as "advice to implementors".
> 
> I don't see such stuff as part of the spec.  If someone wants
> to write a 'guideline for WM authors' that's fine, but it
> has little to do with interclient communication.

Little, but not nothing. It's a recommendation about
how a window manager should behave in order that its
clients can count on certain code (using window
gravity) working properly.

But I'd freely admit that the main reason I posted
here is the audience of window manager authors.
 
> > When opaque-resizing a window from the left, one frequently
> > sees "jumping" as center or right-aligned subwindows
> > are translated to the left and then repositioned into
> > place. X has a mechanism for controlling such behavior -
> > window gravity. By using either static gravity or
> > the appropriate gravity for an aligned element, this
> > artifact should be controllable.
> > 
> > However, the way most reparenting window managers implement
> > resizing defeats window gravity. Such window managers
> > first XMoveResizeWindow() the frame window into the right
> > place, and then XResizeWindow() the client window to 
> > the right size.
> > 
> > The correct behavior (in my opinion) is to set 
> > window gravity for the client window to StaticGravity,
> > then when a resize occurs. 
> > 
> >  - If the resize makes the window bigger:
> >    
> >    1) XMoveResizeWindow the client window to the new size and position
> >    2) XMoveResizeWindow the frame window to the new size and position
> > 
> >  - If the resize makes the window smaller:
> > 
> >    1) XMoveResizeWindow the frame window to the new size and position
> >    2) XMoveResizeWindow the client window to the new size and position
> > 
> >  - If the resize does opposite things in the two dimensions, 
> >    do one of the above sequences arbitrarily - you'll get a bit 
> >    of flashing around the border, as regions are temporarily exposed, 
> >    just as you would when doing things the "old-fashioned" way.
> 
> I've spent the morning experimenting with this in fvwm.  Your
> approach suffers from the same problem: if you resize the frame
> window first when the window gets bigger, you will se the WM
> border flashing instead of e.g. a scrollbar.  That's nor any
> better.  

The ordering of resizes is rather incidental to my 
recommendation. The important part is using a MoveResize
on the client window instead of moving the frame window
and then reszing the client window.

That is, the appearance of the borders during opaque 
resizing depends on the resize sequence, and the best
sequence there probably depends on the exact geometry
of the frame windows and decorations, but using 
MoveResizeWindow and static gravity to move the client
window should be relatively universal.

(As an addition to what I said earlier, it's probably
good to only set win_gravity on the client window
during the resize operation and restore it afterwards
so if the window manager is killed it is less likely
to confuse other window managers that may not expect
this.)

Regards,
                                        Owen