From: Owen Taylor Subject: Suggestion: Gravity and resizing from the left To: wm-spec-list@gnome.org Date: 17 Nov 1999 15:30:55 -0500 Resent-From: wm-spec-list@gnome.org Reply-To: wm-spec-list@gnome.org X-From-Line: wm-spec-list-request@redhat.com Wed Nov 17 12:32:33 1999 Received: from lists.redhat.com (lists.redhat.com [199.183.24.247]) by june.cs.washington.edu (8.9.3/8.9.3/0.3j) with SMTP id MAA15614 for ; Wed, 17 Nov 1999 12:32:29 -0800 (envelope-from wm-spec-list-request@redhat.com) Received: (qmail 4989 invoked by uid 501); 17 Nov 1999 20:32:27 -0000 Resent-Date: 17 Nov 1999 20:32:27 -0000 Resent-Cc: recipient list not shown: ; MBOX-Line: From wm-spec-list-request@gnome.org Wed Nov 17 15:32:27 1999 Message-ID: User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"E_svq.0.nD1.R3nCu"@lists.redhat.com> X-Mailing-List: archive/latest/147 X-Loop: wm-spec-list@gnome.org Precedence: list Resent-Sender: wm-spec-list-request@gnome.org X-URL: http://www.redhat.com Lines: 53 Xref: clavicle.cs.washington.edu wmspeclist:437 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 wm-spec-list-request@gnome.org with "unsubscribe" as the Subject. From: Owen Taylor Subject: Re: Suggestion: Gravity and resizing from the left To: dominik.vogt@gmx.de Cc: wm-spec-list@gnome.org Date: 21 Nov 1999 21:49:24 -0500 Resent-From: wm-spec-list@gnome.org Reply-To: wm-spec-list@gnome.org X-From-Line: wm-spec-list-request@redhat.com Sun Nov 21 20:06:11 1999 Received: from lists.redhat.com (lists.redhat.com [199.183.24.247]) by june.cs.washington.edu (8.9.3/8.9.3/0.3j) with SMTP id TAA06997 for ; Sun, 21 Nov 1999 19:47:32 -0800 (envelope-from wm-spec-list-request@redhat.com) Received: (qmail 16074 invoked by uid 501); 22 Nov 1999 03:47:28 -0000 Resent-Date: 22 Nov 1999 03:47:27 -0000 Resent-Cc: recipient list not shown: ; MBOX-Line: From wm-spec-list-request@gnome.org Sun Nov 21 22:47:27 1999 References: <19991121123115.A13988@gmx.de> In-Reply-To: Dominik Vogt's message of "Sun, 21 Nov 1999 12:31:15 +0100" Message-ID: User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"mgAmz.0.hw3.FpBEu"@lists.redhat.com> X-Mailing-List: archive/latest/160 X-Loop: wm-spec-list@gnome.org Precedence: list Resent-Sender: wm-spec-list-request@gnome.org X-URL: http://www.redhat.com Lines: 89 Xref: clavicle.cs.washington.edu wmspeclist:450 Dominik Vogt 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 wm-spec-list-request@gnome.org with "unsubscribe" as the Subject. From: Dominik Vogt Subject: Re: Suggestion: Gravity and resizing from the left To: wm-spec-list@gnome.org Date: Mon, 22 Nov 1999 10:18:44 +0100 Reply-To: dominik.vogt@gmx.de Resent-From: wm-spec-list@gnome.org X-From-Line: wm-spec-list-request@redhat.com Tue Nov 23 12:06:18 1999 Received: from lists.redhat.com (lists.redhat.com [199.183.24.247]) by june.cs.washington.edu (8.9.3/8.9.3/0.3j) with SMTP id MAA01290 for ; Tue, 23 Nov 1999 12:06:17 -0800 (envelope-from wm-spec-list-request@redhat.com) Received: (qmail 14847 invoked by uid 501); 23 Nov 1999 18:01:44 -0000 Resent-Date: 23 Nov 1999 18:01:44 -0000 Resent-Cc: recipient list not shown: ; MBOX-Line: From wm-spec-list-request@gnome.org Tue Nov 23 13:01:44 1999 X-Authentication-Warning: DarkSun.nodomain: luthien set sender to dominik.vogt@gmx.de using -f Message-ID: <19991122101844.A648@gmx.de> Mail-Followup-To: wm-spec-list@gnome.org References: <19991121123115.A13988@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Owen Taylor on Sun, Nov 21, 1999 at 09:49:24PM -0500 Resent-Message-ID: <"d5zwH.0.dd3.8QjEu"@lists.redhat.com> X-Mailing-List: archive/latest/164 X-Loop: wm-spec-list@gnome.org Precedence: list Resent-Sender: wm-spec-list-request@gnome.org X-URL: http://www.redhat.com Lines: 52 Xref: clavicle.cs.washington.edu wmspeclist:454 On Sun, Nov 21, 1999 at 09:49:24PM -0500, Owen Taylor wrote: > > Dominik Vogt 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 ^_^