[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-ui-dev] Patch for better View Resize behavior
|
Randy,
Yes, the new behaviour is better. However, I should get this behaviour
immediately, and should not have to resize things first (yes, I closed all
perspectives first).
I don't think perspectives should have to do anything differently.
And there's some new, unwanted behaviour: if I close all perspectives then
open the resource perspective, the -window- jumps around (if not
maximized), apparently centering itself on the screen!
Could you look into these issues? It would be better to carry this on in
the PR.
Nick
Nick Edgar
11/28/02 02:46 PM
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