Re: Suggestion: Gravity and resizing from the left

[Dominik Vogt <dominik vogt fvwm org>]

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.

> 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.  This can be resolved if the border is drawn in a window
that is stacked below the client window.  This is all extremely
difficult to do right.  Even if the spec was the right place for
such things it would not help at all to state 'you have to do it
this way' because that doesn't buy you anything for the
implementation.  Detailed sample code would be necessary too.

> Do any window managers do this already?

If you're interested in what I'm doing with fvwm now you can
fetch the latest snapshot or CVS code when I've committed my
code.

Bye

Dominik ^_^

--
Dominik Vogt, dominik.vogt@gmx.de
Reply-To: dominik.vogt@gmx.de