Community
Participate
Working Groups
Post V2, but I'm reporting it anyway: When the workbench window is resized, the various docked views such as outline and navigator are also resized. This should only resize the EditorPane, with all other views staying a fixed size while size permits. The fact that all views are resized means the User is constantly resizing Views after changing the workbench window size. The User cannot grow just the EditorPane area, which is very common. Or, when the window is maximized and the User "restores" it to do something like DND with File Explorer, all docked views get smaller.
Agree. Should consider edges adjacent to editor area as unconstrained, and resize only the editor area if possible. However, would still need to resize views proportionally, e.g. if two views are docked next to each other on the bottom and you resize horizontally.
Reopened for investigation
I understand the lower priority, but why was this changed to enhancement? I'm sure the layout code is working as designed, but I think the design is flawed. Views should not resize when I resize the WorkbenchWindow. I still consider this a bug. I hope you can fix this for 2.1.
Changing this back to "normal". The current behavior is wrong, and cannot be found in similar products, such as Visual Studio, or even explorer.exe
>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. This can work. When setBounds(Rectangle) is called for the first time, Ratios that are between 0.0 and 1.0 can be converted to fixed-width ratios, and then the new value can be set back into the perspective. I'm not sure if perspectives should make changes to take advantage of fixed- sizes. Probably they should if they know the minimum resolution. Or, you could take the ratio and multiply it by 800x600 pixels, assuming that is the minimum resolution. Off topic, but the first time a user resizes a sash, he should be prompted that his changes can be saved by re-saving the perspective. >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! This didn't happen with me during devlopement on M3. Can you reproduce this on M3?
The definition of "bias" is in the method JavaDoc, it is not related to aspect ratio.
Created attachment 2612 [details] Resize patch for M3 In this patch, ratios are converted to fixed sizes immediately. The user does not have to resize the Sash first. I had to check for the scenario of a perspective opening in a new window. (lucky for me, I always work in that mode). For some reason, a layout is performed when the Composite is width==height==0. I had to add a check to ignore this layout.
Eduardo, could you please review Randy's patch? I'd prefer not to reuse the ratio field.
In the patch, I renamed "ratio" to "sashLocation". But, it's definition is overloaded. If the location is between 0.0-1.0, it means a percentage. If it is >1.0, it means a fixed distance. If you make it so that there are 2 separate properties, it is never meaningful to use both. If this gets surface in plugin.xml files, it will probably be confusing either way. oh well..
- I would opt to have a second property. - I will not have the time to merge/change/test this code for M4. Randy, if you have the time to apply these changes on top of M4, (once we have it) I will try to release it when I get the changes so we do not have to merge code. If you do not have the time, I will try to do it for M5.
There are no plans for the UI team to work on this defect until higher priority items are addressed.
I have continued to maintain and use this patch in 2.1. It is part of my UI hacks download. I have not heard of or seen any problems using it. You can download the 2.1.0 version of it from: http://dev.eclipse.org/viewcvs/index.cgi/gef-home/team/?cvsroot=Tools_Project
Please schedule a 3.0 milestone for this patch. Obrigado :-)
Eduardo, if we add second property, its use will be mutually exclusive from the currently existing property. And, you will have to add a THIRD property (a boolean), to indicate which of the other two properties should be used to determine size. Also, new API would be required for these new properties. On the other hand, extending the use of the existing property requires no new fields, and no new API. You would simply have to broaden the definition of the current API. Let me know what you want to do. I will re-write this feature if you want separate fields.
We are placing the GEF palette inside a workbench view. The palette layout is very sensitive to view width. It places the items in a column layout, wrapping buttons from left to right. So, if the view width is constantly changing, the user does not know where to find their palette items. BTW, my patch does not handle hide/show editor area :-P. When the editor area goes away, layout nodes which used to have a compression bias will no longer have the bias, so they need to go back to using ratios. So finally, a reason to have two separate properties, one a ratio, and one in pixels. As far as behavior, I think that only one of the two properties should be update when the sash is dragged. Obviously, it would be the property that is currently affecting the layout (ratio or absolute size). Therefore, when you toggle editor visibility, it would be like having separate sash locations for with and without editor visibility.
Michael, we were planning on including Randy's patch but it got lost in the team shuffle last year. I just found out that some of the views in Lotus Workplace also care about maintaining a constant width (see bug 51580). We should look at changing the resize behaviour as described, although I never liked the way the patch overloads the ratio/sashLocation field as describe above in comment #9. Not sure if this patch will still be valid given all the changes that have gone on since it was originally provided, particularly for the new look. Perhaps this is something that Stefan (aka Layout God) could fix up.
stefan, please investage supporting this in the current stream? If the patch is not useful perhaps given the current layout, this may not be too hard to code from scratch.
Stefan, I have been merging this patch into every 3.0 milestone manually, including M7. It still works just fine. However, as mentioned in comment 15, you will want to keep track of both a ratio (0.0 to 1.0), and a fixed-width pixel size (int). The patch only keeps track of one or the other (by overloading a field). So this is problematic when show editor area is toggled. When the user drags a sash, you will always store the new percentage, but only store the new fixed-width pixel size if there is compression bias. Otherwise just hang onto the previous value.
Submitted the easy part of the fix: fastviews now maintain a constant size. I have a question, though: what is the primary concern here? I see two related issues: 1. There are some views that should never be resized. 2. In general it is better to resize the editor area than views. Both are useful, but which one is most important here? Both would be equivalent for views adjacent to the editor area, but item 1 would either require truncating a view or leaving empty space in the workbench when one dimension of the workbench is spanned entirely by non-resizable views.
I think that only 2. is reasonable: It is better to resize the editor area than the views. Consider also: +--+-----+ | | | +--+ edtr| | | | +--+-----+ When resizing height, the two left views are going to grow vertically. So even with the editor visible, 1.) is not possible. Ideally, if there were three left views, they would grow vertically the same amount. This could be acheived, but I digress. If you want to get closer to 1)., in the above case, you could consider some UI to allow the user to fix the height of one of the two views in the vertical column. I have never seen such a UI though. Perhaps there would be no UI, and the plug-in would indicate the views desire to grow/shrink. For example, Progress View doesn't need to grow.
I guess I was unclear: I was specifically trying to refer to the case you mentioned in comment 20. The layout algorithm already supports something close to behavior 1. We needed this to support minimized views (which cannot resize vertically). You can see the effect of a column of fixed-height views by minimizing everything in a column and resizing the workbench window -- it's not pretty, but it maintains the height constraint.
I don't see a problem with minimized views. Obviously they take priority over anything else and can be special-cased to ignore whatever sash location has been set.
There is no problem with minimized views. That's the point. They are an example of a view which cannot be resized vertically, and they demonstrate that case 1 is possible.
I'm going to take a shot at solving this on M8
I have this working now. The behavior is the same as my previous patch, but when the editor area is hidden, it reverts to using ratios instead of fixed sizes. It supports restoring state from ratios, and lazily converting them to fixed sizes. When saved, the layout is saved by saving both the ratio and the fixed size. It is working for rollup, maximize view/editorpane, and with the intro view. Any other test cases? I haven't tried fastviews yet.
Created attachment 9345 [details] Changes on M8 Here is the JAR containing the modified classes for this fix. Instead of reusing the ratio field, I added two new integer fields, left and right. Left and right represent the size in pixels of the top/left and bottom/right parts. When there is no compression bias, the value (float)left/right is used to determine what used to be stored in the ratio field. Ratio field is no longer used except it is supported at startup and can be specified by perspectives or mementos. If the ratio is set, one a layout occurs, left and right will be initialized to their appropriate values, and ratio will be set to 0.0 and no longer used.
Does the patch also maintain the view heights when resizing vertically?
> Does the patch also maintain the view heights when resizing > vertically? yes
Randy, I'm investigating this right now. In the future, it would be a lot easier if you could create a patch file. (right-click on org.eclipse.ui.internal, Team->Create Patch.. -> Save in File System -> Finish)
Created attachment 9508 [details] Previous .jar file, converted into a patch against org.eclipse.ui.internal M8
Created attachment 9509 [details] Same patch, merged with head on 040414 There seems to be a bug with the patch. When loading an existing workspace, all of my views started out at their minimum sizes. After closing and reopening my workspace, everything worked correctly.
Some comments: 1. It appears that left, right, ratio, and the combined bounds of the left and right controls all store the same information. Any of them can be calculated directly from the others, given the bounds of the LayoutTree (which is known during a resize). I suspect that it would be possible to code this using only left and without changing its semantics on the fly. 2. The new PartSashContainer.add(...) method should follow the semantics of addEnhanced(...), and should only take the size of the newly added part as an argument (the size of the other part is already known). 3. I'm not fond of how isCompressible() needs to traverse the depth of the tree, but this is also a problem with isVisible() and fixedHeight(), and it can be fixed later.
Created attachment 9521 [details] Latest patch, with modifications by SX Actually, never mind comment 32. I was confused by the precise meaning of the left/right fields, but they make sense on closer inspection. I've made the following changes: - Fixed the bug in comment 31 - Removed the ratio parameter and lazy initialization of the left and right fields (they are now initialized immediately). - Changed the way ratios are treated on initialization -- rather than using the size of the layout at the first resize event, perspectives are always initialized in 800x600. This means that reset perspective -> resize window -> resize perspective will not modify the perspective on the second reset, and it means that a perspective will always look the same at the same resolution, regardless of the user's initial window size. Unfortunately, it also changes the initial layout of most perspectives. I want a second opinion on this. I also started on a drag/drop patch that uses the new resize behavior to avoid resizing views during drag/drop wherever possible... but I backed out of it for now because that can be handled as a seperate feature. Some stuff that still needs to be done before we can check this in: 1. LayoutPartSash needs JavaDoc to describe the precise meaning of left/right/getLeft()/getRight(). 2. WorkbenchPage.resizeView relies on ratios to work properly. I took a glance over the code, and it looks like this method wasn't working correctly anyway and it doesn't seem to be used. Nick, can you confirm if it's okay to remove this? If not, we'll need to bring it up to date with the new layout code.
Note: with this patch, it's quite easy to make the editor area disappear entirely by reducing the size of the window. We may also want to address this (perhaps the editor area can have some minimum size before we start resizing views).
Please do not delete resizeView. This is work in progress. See bug If it's currently broken, or needs to be fixed up for this patch, could you please take care of it, or advise on how it should be fixed up in bug 51580?
There is already support in the LayoutPart hierarchy for minimum size. See LayoutPart.getMinimumWidth() and getMinimumHeight(). It looks like this doesn't work too well currently for views. E.g. in a new Java perspective, shrink the Problems view to its minimum height. It shows some extra highlights, and the status area overlaps. It should look the same as if the view was minimized.
I was unclear. Comment 34 isn't referring to a minimum size for the editor area. It is suggesting a size below which editors will be resized with the same priority as views.
isCompressible() could be implemented to return false at some magical small size. But you would have to know if the person asking is trying to compress you horizontally or vertically. The editor pane may be really short, but have plenty of width for compressing. So, isCompressible could return and INT which would be a bitwise ORing of SWT.HOROZONTAL and SWT.VERTICAL.
Re: comment 38 This won't work. In order to do this, the editor area must have already been resized to something too small. This means that you'll get a different layout if you resize quickly and if you resize slowly. The layout should be entirely determined by the size of the window. BTW, I wonder if isCompressable() should really be a method on LayoutPart. This seems to be an attribute of the PartSashContainer, not of its child parts.
I know what you mean. In Draw2d, we have a very elaborate layout mechanism. The equivalent here would be: boolean isCompressible(int wHint, int vHint); And sashpartcontainers would call: left.isCompressible(wHint - getRight(), vHint) and similarly, for the right part, and for vertical orientation.
Created attachment 9834 [details] Updated patch After chatting with Michael, we agreed that downstream perspectives won't like having their initial layout changed. I've made this behave more like Randy's original patch WRT initial view sizes. I've updated it to work with WorkbenchPage.resizeView and Nick's recent PartSashContainer changes, but I haven't tested these yet.
Fixed in head. For the final version of the patch, I changed the load/save state methods to handle missing attributes without NPEs, and support saving workspaces that can be loaded by earlier versions of Eclipse.
*** Bug 44954 has been marked as a duplicate of this bug. ***
