From: Arnout E. <no...@bz...> - 2011-02-12 01:36:02
Attachments:
lazyresize.diff
|
Hi, When a frame holds multiple tabs and gets resized, all multiplexed client windows are directly resized. Some applications, such as Oracle VirtualBox, appear to send an XConfigureRequestEvent requesting the window to be raised whenever they are resized. Since http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=519a5fdccf5ab27e55436d11098b8631fd3f1218 we honour those requests. This, of course, makes it more obvious (and annoying) that these clients are misbehaving (at least it seems like misbehaviour to me). To prevent hitting such problems, it might make sense to resize only the visible client window and leave the hidden ones alone. When switching windows, we'd have to perform the resize on the window you switch to (if needed). Attached is a simple patch that does that. I'm not so sure I like it though: it makes switching tabs after a resize a bit slower because the resize has to be performed. On the other hand we're no longer bothered by hidden windows doing funny stuff when resizing their frame. What do you think? Kind regards, Arnout |
From: Ole J. B. <ole...@ya...> - 2011-02-12 04:08:23
|
My brother have used a variant of this patch (seems to be about the same changes) for a long time now. He uses a nested frame without tab decorations to organize his browser windows. When the number of windows in that frame grow, resizing became very slow without the patch, so it actually a valid concern from a performance standpoint too. I don't think he has experienced a lot of weird side effects. An option is to make it controllable by a winprop? - Ole Jørgen Brønner / olejorgenb On Sat, 12 Feb 2011 02:35:50 +0100, Arnout Engelen <no...@bz...> wrote: > Hi, > > When a frame holds multiple tabs and gets resized, all multiplexed client > windows are directly resized. > > Some applications, such as Oracle VirtualBox, appear to send an > XConfigureRequestEvent requesting the window to be raised whenever they are > resized. > > Since http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=519a5fdccf5ab27e55436d11098b8631fd3f1218 > we honour those requests. This, of course, makes it more obvious (and > annoying) that these clients are misbehaving (at least it seems like > misbehaviour to me). > > To prevent hitting such problems, it might make sense to resize only the > visible client window and leave the hidden ones alone. When switching windows, > we'd have to perform the resize on the window you switch to (if needed). > > Attached is a simple patch that does that. I'm not so sure I like it though: > it makes switching tabs after a resize a bit slower because the resize has to > be performed. On the other hand we're no longer bothered by hidden windows > doing funny stuff when resizing their frame. > > What do you think? > > > Kind regards, > > Arnout |
From: Arnout E. <no...@bz...> - 2011-02-13 22:16:18
Attachments:
lazyresize.diff
|
On Sat, Feb 12, 2011 at 05:08:13AM +0100, Ole Jørgen Brønner wrote: > My brother have used a variant of this patch (seems to be about the same > changes) for a long time now. > > He uses a nested frame without tab decorations to organize his browser > windows. When the number of windows in that frame grow, resizing became > very slow without the patch, so it actually a valid concern from a > performance standpoint too. Interesting > I don't think he has experienced a lot of weird side effects. > > An option is to make it controllable by a winprop? I gave it a shot, patch attached. The winprop is called 'lazy_resize', so for example: defwinprop{ class = "VirtualBox", lazy_resize = true } Because the client windows may not be a direct child of the mplex (at least it looks like there's usually a WGroupCW in between), it seemed like a reasonable idea to move that logic to clientwin_fitrep instead. To seperate resizing and reparenting a bit more neatly, I moved the REGION_GEOM(cwin)=geom assignment to happen after reparenting instead of before. This seems to work beautifully here - but I'd be glad if you guys could test and review the changes a bit. Kind regards, Arnout > On Sat, 12 Feb 2011 02:35:50 +0100, Arnout Engelen <no...@bz...> wrote: > >> Hi, >> >> When a frame holds multiple tabs and gets resized, all multiplexed client >> windows are directly resized. >> >> Some applications, such as Oracle VirtualBox, appear to send an >> XConfigureRequestEvent requesting the window to be raised whenever they are >> resized. >> >> Since http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=519a5fdccf5ab27e55436d11098b8631fd3f1218 >> we honour those requests. This, of course, makes it more obvious (and >> annoying) that these clients are misbehaving (at least it seems like >> misbehaviour to me). >> >> To prevent hitting such problems, it might make sense to resize only the >> visible client window and leave the hidden ones alone. When switching windows, >> we'd have to perform the resize on the window you switch to (if needed). >> >> Attached is a simple patch that does that. I'm not so sure I like it though: >> it makes switching tabs after a resize a bit slower because the resize has to >> be performed. On the other hand we're no longer bothered by hidden windows >> doing funny stuff when resizing their frame. >> >> What do you think? >> >> >> Kind regards, >> >> Arnout |
From: Arnout E. <no...@bz...> - 2011-02-19 01:39:48
|
On Sun, Feb 13, 2011 at 11:16:08PM +0100, Arnout Engelen wrote: > I gave it a shot, patch attached. The winprop is called 'lazy_resize', so for > example: > > defwinprop{ > class = "VirtualBox", > lazy_resize = true > } > > Because the client windows may not be a direct child of the mplex (at least > it looks like there's usually a WGroupCW in between), it seemed like a > reasonable idea to move that logic to clientwin_fitrep instead. > > To seperate resizing and reparenting a bit more neatly, I moved the > > REGION_GEOM(cwin)=geom > > assignment to happen after reparenting instead of before. > > This seems to work beautifully here - but I'd be glad if you guys could test > and review the changes a bit. Patches committed (and documented). Arnout |