adam@bsw.UUCP (Adam R de Boor) (07/19/89)
In the R2 VPaned widget, if I had a pane whose allowResize resource was true and that pane issued a resize request, rather than resizing the whole vpaned object, it would resize the requesting pane, then grow or shrink a nearby pane to match. Under R3, the shell just resizes itself to accomodate the new pane, which isn't what I want (frequently, even when the shell does resize itself, the requesting pane doesn't actually resize -- some other pane does). (a) why did this change (b) is there any way to get the R2 behaviour? I'll even accept an answer along the lines of: In R4, the VPaned geometry manager will perform XtQueryGeometry calls, setting the CWHeight bit and passing the height it would like to make a pane, dealing with the result and finally adjusting all the panes to accomodate a request from an allowResize pane, only asking the shell to make it bigger if it comes up against some hard limit (like all other panes are at their min size). a
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (07/26/89)
> In the R2 VPaned widget, if I had a pane whose allowResize resource was true > and that pane issued a resize request, rather than resizing the whole > vpaned object, it would resize the requesting pane, then grow or shrink a > nearby pane to match. Under R3, the shell just resizes itself to accomodate the > new pane, which isn't what I want (frequently, even when the shell does > resize itself, the requesting pane doesn't actually resize -- some other pane > does). > (a) why did this change I don't know. > (b) is there any way to get the R2 behaviour? What about setting allowShellResize to False? This will certainly keep the VPane widget from resizing, although it may also keep the child pane for resizing too, I don't remember how the R3 VPaned widget acted. > I'll even accept an answer along the lines of: In R4, the VPaned geometry > manager will perform XtQueryGeometry calls, setting the CWHeight bit and > passing the height it would like to make a pane, dealing with the result and > finally adjusting all the panes to accomodate a request from an allowResize > pane, only asking the shell to make it bigger if it comes up against some > hard limit (like all other panes are at their min size). The R4 Paned widget takes an approach that is a bit of both. It knows the preferred size of each pane (by default this is obtained by an XtQueryGeometry call). If a pane can be moved closer to its perferred size then that is done and the Paned widget does not try to change it size. If no pane can be moved closer to its perferred size then the Paned widget asks its Parent to change its size to accomadate the new pane. If the parent allows the change everyone is happy, but if the parent disallows the change then the Paned widget will force some of its children to move away from their preferred size (never going past the min and max). The idea is to keep every child as close to its perferred size as possible. Sure the parent is required to manage that size of the Paned widget, but that is how geometry management is Xt is supposed to work :-) Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213