Community
Participate
Working Groups
3.0, GTK+ 2.4.1, KDE 3.2.2, Linux 2.6.7. STEPS TO REPRODUCE: 1.) Make the workbench window some arbitrary smaller size. 2.) Reset perspective. 3.) Maximize the workbench window. 4.) Reset the perspective. OBSERVED RESULTS: At step #3, the views do not resize (e.g., package explorer, navigator, etc.). At step #4, the views resize themselves. DESIRED RESULTS: At step #3, the views should resize. Step #4 should have no effect. This is the same behaviour as in 2.1.3. This is related to Bug 44954. In fact, I'm asking for the opposite. In my workflow, I frequently maximize Eclipse to try to make more room for the views (such as the package explorer). There is usually something cut off or otherwise unreadable. By not allocating space proportionally amongst all the views, I am forced to reset the perspective myself. I also find it somehow wrong that maximizing a window means that the perspective is now "changed" (i.e., resetting changes its layout).
Bug 44954 reports the intended behavior. This was fixed in bug 19524. Most views (such as the package explorer or outline view) have a width or height beyond which they are not useful, whereas most editors are able to take advantage of extra space if it is available. For this reason, priority is given to editors when the workbench window grows. I will not flag this as WONTFIX because you are correct in that step 4 should have no effect. The reason for this is that perspectives are specified in terms of ratios of the window size, and we use the current window size rather than some absolute window size. The current behavior means that perspectives will look slightly different based on the window size when the perspective first becomes visible, which is somewhat bogus. Renaming bug. I would suggest adding an optional "window size" attribute to perspectives, meaning that all ratios should be interpreted with respect to the given window size rather than the current window size. This would ensure that reset perspective will have the same effect regardless of the current window size. (In this case, step 3 will still not resize views but step 4 will have no effect).
Stefan, I would suggest trying the following. Make your Eclipse window small (800x600 or so) and reset the perspective. Then maximize. I disagree with your statement that views cannot use extra space. Even ignoring the above example, looking at views such as the search/problems view (vertical space) or even a package explorer opened several levels deep (horizontal space). I still don't feel Bug 44954 should represent the intended behaviour. Can you give an example of another application that uses similar sizing behaviour?
This is not a problem with the new layout behavior, but it is a problem with the way in which perspectives are described. The extension point needs to support the new LEFT and RIGHT properties which were added to the part layout mechanism. Add the following Step to your test case and it is invalid: 0.) Make some changes to the perspective and invoke "Save As" and overwrite the defaults. If you do this, the LEFT and RIGHT components *are* persisted, and resetting the perspective has no effect in step 4). So, what is needed is the ability to specify absolute sizes in the plugin.xml instead of just ratios. Client would only need to specify and absolute size for one side.
Regarding comment 3: You are correct that this is a problem in how perspectives are described. However, specifying absolute sizes is equivalent to specifying a ratio and a window size. Since absolute sizes are often used as a ratio and existing perspectives already use ratios, perspective authors are likely to find "ratio + window size" more intuitive than "left + right". Regarding comment 2: True, the amount of space needed for the package explorer can change over time. I didn't mean to suggest otherwise. Let me rephrase comment 1: Premise: 1. Most users wish to make the editor area as large as possible without shrinking views to the point that they become useless (usability assumption). 2. The minimum useful size of a view may vary over time, but is not a function the current window size. 3. The window size may change over time, but not necessarily for the purpose of fitting the contents of some view. Stated precisely, the ideal layout would be: 4. No view is smaller than its minimum useful size 5. Editors occupy all remaining space (less important than 4) If we resized views proportionally to the window, then making the window larger could be used to fix constraint 4 when a view's useful size grows, but it would violate constraint 5. It would also violate both constraints whenever the window size shrinks or changes for any other reason than to compensate for the contents of a view. The only way to satistfy both constraints is to allow the user to specify view sizes independently of the window size. If I understand correctly, sounds to me like you want to satisfy constraint 4, but you find resizing the window to be so much more convenient than resizing the view that you are willing to sacrifice constraint 5. If this is the case, then resizing views isn't convenient enough, and we should fix that.
Correction to comment 4: I should have said: 5. Editors occupy as much space as possible without violating constraint 4.
Correction to premise #1: Most users want to maximize vertical editor space, and have editors occupy a certain minimum width (usually defined by their code formatter and font size). I also disagree with premise #5. I want the views and editors to balance the available space. Several views become more useful with more space. To name a few: outline (vertical), problems (vertical, large minimum width), junit (stack traces, horizontal), package explorer (horizontal). I like to use the default perspective layout; I never want to resize views. Resizing views enters into a situation where you are constantly clicking and dragging (i.e., fiddling) with view/editor sizing. It is much easier to just let the layout handle it. I find the constant clicking/dragging hard on my hands. It is also not keyboard accessible.
Regarding comment 6, (and this sounds familiar) everything is not a source editor. There are other types of editors for which "print margin" does not mean anything. There are even editors which extend horizontally and not vertically, so the vertical argument doesn't apply. There are also source editors where intendation is more important than width and there is no print margin. Examples of programs in which only the "editor pane" is resized: 1) Windows Explorer 2) Internet Explorer 3) Lotus Notes 4) Microsoft Visual Studio 5) Outlook Express ...
Re: comment 6 If you need more space for a view, you need to resize _something_. The question is merely whether that should be the window or the view itself. Your argument seems to be that maximizing the window requires less user input than resizing a view, so it is more convenient to solve the problem that way. This is not an optimal solution because maximizing the workbench window would waste space by expanding every view and editor -- not just the one that needs extra space. Perhaps we should add an option and associated hotkey allowing the user to "resize to fit contents". This would only affect the view or editor with focus. It could be activated with a single keystroke and would not waste space by giving extra space to panes that don't need it. BTW, resizing views is keyboard accessable (alt-minus, s).
I have a bugzilla open on the fact that Sashes are 3-pixels wide in Eclipse, but Windows File Explorer uses 6 pixels.
It's true that sashes are hard to click on in Eclipse. But even once that is fixed, I suspect Doug would still like a way to make an interesting view larger which doesn't require any dragging at all.
Definitely this would be cool. I had considered a behavior for resizing views: A view (or column of views) such as the navigator view would have: - minimum width required - user specified width when active - user specified width when in background Based on whether the view is active, it's foreground or background size could be used. The background size cannot be bigger than the foreground size. Use the minimum width whenever it is smaller than the user-defined size. But, you'd have to layout often and you'd need to depend on the parts to fire min size changed.
Actually, I've recently added code to HEAD that allows this type of thing and a lot more (you can have quantized preferred sizes, max size, min size, or other constraints that can change programmatically). I've tested constraints that maintain a minimum area, minimum perimeter, or keep the width of all views a multiple of 100 pixels. Right now this stuff is available to the presentation layer, but I'm still trying to work out if this should be made available to individual views or editors. IMHO, it would be really annoying if a view or editor changed size on its own.
see bug 81460
Reassigning the last of Stefan's bugs.
Is this still a problem in 3.3? PW
Changes requested on bug 193523
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
