Subject: Suggestion: Gravity and resizing from the left
From: Owen Taylor <[email-masked]>
To: [email-masked]
Date: 17 Nov 1999 15:30:55 -0500

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".

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.

Do any window managers do this already? (I've seen the 
"incorrect" behavior with some versions of Fvwm, 
Enlightenment, and Sawmill, so it is pretty common.)

Hope this is useful,
                                        Owen

-- 
To unsubscribe: mail [email-masked] with "unsubscribe"
as the Subject.

From: Owen Taylor <[email-masked]>
Subject: Re: Suggestion: Gravity and resizing from the left
To: [email-masked]
Cc: [email-masked]
Date: 21 Nov 1999 21:49:24 -0500
Resent-From: [email-masked]
Reply-To: [email-masked]
Resent-Date: 22 Nov 1999 03:47:27 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From [email-masked]  Sun Nov 21 22:47:27 1999
Resent-Message-ID: <"mgAmz.0.hw3.FpBEu"@lists.redhat.com>
Resent-Sender: [email-masked]
Lines: 89
Xref: clavicle.cs.washington.edu wmspeclist:450

Dominik Vogt <[email-masked]> 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

-- 
To unsubscribe: mail [email-masked] with "unsubscribe"
as the Subject.

From: Dominik Vogt <[email-masked]>
Subject: Re: Suggestion: Gravity and resizing from the left
To: [email-masked]
Date: Mon, 22 Nov 1999 10:18:44 +0100
Reply-To: [email-masked]
Resent-From: [email-masked]
Resent-Date: 23 Nov 1999 18:01:44 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From [email-masked]  Tue Nov 23 13:01:44 1999
Mail-Followup-To: [email-masked]
Resent-Message-ID: <"d5zwH.0.dd3.8QjEu"@lists.redhat.com>
Resent-Sender: [email-masked]
Lines: 52
Xref: clavicle.cs.washington.edu wmspeclist:454

On Sun, Nov 21, 1999 at 09:49:24PM -0500, Owen Taylor wrote:
> 
> Dominik Vogt <[email-masked]> writes:
> > 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.

The hard part was to get the decoration windows into
the picture.  I'm a bit disappointed about tha applications.
I tried xterm, rxvt (with backgroiund pixmap), netscape,
xman and xv and none of the is intelligent enough to
reduce redrawing based on the areas that have been exposed.
rxvt 2.7.1 has some improved ConfigureNotify code, but I
didn't try that yet.  I must say that the six hours I needed
were not very well spent; opaque resizing is still
worthless except for selected applications.  Netscape
4.61 for example freaks out completely.  I have seen it
redrawing for about thirty seconds after I released the
mouse because it's too stupid to throw away all but the last
ConfigureNotify event in a row.

> 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.

Static Gravity seems to be broken with XFree 3.3.3.4.
At least it doesn't work on grandchildren of top level
windows.
 
Bye

Dominik ^_^