Re: [platform-ui-dev] Patch for better View Resize behavior

["Nick Edgar" <Nick_Edgar@xxxxxxx>]

This feature sounds like a waste of effort. 
No one is asking for this or really needs it.

Oh wait, I'm not Randy <g>.  Actually, I see that you did ask for this in 
bug 19524, and that I agreed with you.

I'm not sure I understand the extra complexity about using either a ratio 
or a fixed size based on the "bias" of the layoutTreeNode (I assume by 
"bias" that you mean whether it is squashed more horizontally or 
vertically).  I think it would be more straightforward if it just always 
resized the editor area.  If resizing views is unavoidable (e.g. views are 
above or below the editor area when resizing horizontally, or to the left 
or right of the editor area when resizing vertically), then the views 
involved should resize proportionally (splitting the difference evenly 
between them).  If a view is attached to the same edge as the editor area, 
then it should resize along with the editor area.

I'll check out the patch.

Nick








Randy Hudson <hudsonr@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
11/28/02 11:36 AM
Please respond to platform-ui-dev

 
        To:     platform-ui-dev@xxxxxxxxxxx
        cc: 
        Subject:        [platform-ui-dev] Patch for better View Resize behavior



Background: 
Users try to make Views as small as possible while still displaying useful 
information.  For example, the Packages view is made wide enough do 
display the project and package names entirely.  Once you have achieved 
this size, you don't want the view's width/height to change when doing 
other things. 

Problem: 
WorkbenchWindow uses a ratio to split the left and right (top and bottom) 
sides of a sash. 
1) When you resize the workbench window, views get smaller or larger. 
2) Resizing a vertical sash on the left side of the workbench may or may 
not move the vertical sash on the right side (see Java Perspective). 
 Whether or not this happens is based on an internal structure of a binary 
tree that is not known to the User. 

Solution: 
When possible, the EditorArea should be made larger and smaller, and views 
stay the same size.  This means that instead of a ratio, *some* sashes 
should be at a fixed location. My patch reuses the ratio field in 
LayoutPartSash to store the fixed size in pixels. Reuse makes sense 
because a Sash can never be both fixed and proportional. 
Previously, values between 0.0 and 1.0 were used to represent a ratio. 
 Now, values greater than 1.0 can also be used to represent a fixed size. 
 The fixed size is applied to whichever side (top/bottom, left/right) is 
*not* "springy", for lack of a better term.  When a sash is resized, the 
ratio is set to either a ratio (0-1) or a fixed size (> 1.0), based on the 
"bias" of the layoutTreeNode. 

This change is backwards compatibly because it still uses ratios from 
0.0-1.0.  When using this patch, existing perspectives WILL NOT show the 
described resize behavior until they are manually resized by the User. 
 The Users sizes will not be saved unless they re-save the current 
perspective.  Existing perspectives should redefine their ratios to take 
advantage of this (I think this is safe, as long as you don't allocate 
more than 800 pixels wide and 600 pixels tall), OR ratios could be 
converted to fixed sizes after the perspective has been "realized". 




Randy Hudson