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

[Randy Hudson <hudsonr@xxxxxxxxxx>]

If you have the Editor area on the right,
and two Views on the left, one above the other, then the horizontal LayoutPartSash
(dividing the two views vertically) has no bias, so ratio is used.  (It
does what you described).
BTW, the patch is derived from M3.

"Nick Edgar" <Nick_Edgar@xxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 11/28/2002 02:46 PM Please respond to platform-ui-dev

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

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



_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev