Community
Participate
Working Groups
Currently, IPageLayout provides some control over perspective layout. For views, we can: - control initial position - prevent movement and closing through IViewLayout - prevent stacking through standalone views - remove the titlebar (for standalone views) All this is good, but we are discovering that our enterprise RCP applications require more control over perspective layout. Our UI designers want the ability to: 1) Prevent the resizing of views. We are creating simple, "selector" views that aid in navigation. Allowing these views to be resized results in either wasted space (when they are made too large), or confusion (when they are made too small, obscuring the buttons inside). Incidentally, bug 97598 asks for a way to specify a view's size in absolute terms, rather than the fractional value allowed today. This feature would be especially useful for the fixed dimensions of a non-resizable view. 2) Set boundaries on the size of views. For some views, it would be helpful to set minimum and maximum sizes. Among other things, this would help avoid the problem of a view growing too large as it expands to take up space created by the deletion of some other view. Controlling the size of minimized views would also be useful. 3) Suppress the ability to minimize and/or maximize a view. The minimize behavior is especially confusing for some novice users, so we'd like to leave it out completely, at least in some situations. This request is similar to bug 91596, but the idea here is to remove the function completely, rather than just save space on the toolbar. 4) Control the presentation of the icons for the view menu, view minimize, and view maximize. Our user testing showed that users easily missed the menu icon and even after being told, were not recalling where it was. Our workaround was to put something more explicit on the view's toolbar, but it would be cleaner if the existing icons could be replaced and perhaps augmented with text. 5) Lock a view to one edge of the page. We want to design layouts where a view is always on, say, the left edge. As a partial solution, we can make the view non-movable and standalone and position it on the left edge. However, the user can indirectly move the view simply by moving some other view between the standalone view and the edge of the layout. Some alternate solutions we've considered for item 5: - Fixed perspectives. This solves the problem, but at a too-high cost. We don't want to sacrifice the ability to dock *all* the views in our layout. - Replacing views with composite widgets on the workbench window. We've prototyped a solution, overriding WorkbenchWindowAdvisor.createWindowContents(), to add the "locked content" as composite widgets on the workbench window's shell. But once you step outside the world of views and perspectives, some things get complicated. If my app has multiple perspectives, I have to worry about (perhaps) manually hiding these special composites when certain perspectives are shown. And I also need to consider what happens when views are maximized. I may want to hide the composites then as well. Also, there are other negative consequences to overriding createWindowContents() as described in bug 73821.
After reading some about the presentations API, I think that item 4 on my list above could be addressed by creating our own presentation factory. Still, it would be nice if there was a simpler way. I noticed that the 3.3 plan included a proposed item for improving workbench usability (bug 154120). I hope the items in this request will be considered.
>>1) Prevent the resizing of views. We are creating simple, "selector" views Q: By "selector", do you mean that the view contains a fixed list of items? >>2) Set boundaries on the size of views. Q: For min size, do you mean that there'd be a minimum size that the view could be resized down to, but not further? Q: For max size, what would happen, would you just end up with empty space in the workbench? If yes, why is this better than allowing the view to take up this extra space (seems wasted space in the view is no worse than wasted space in the workbench). >>3) Suppress the ability to minimize and/or maximize a view. See bug I just entered, https://bugs.eclipse.org/bugs/show_bug.cgi?id=154311 [Perspectives][ViewMgmt] Need smarter Min/Max view behaviour >>5) Lock a view to one edge of the page. Can you elaborate why this is required? (I can imagine reasons, just want to hear real usage cases).
(In reply to comment #2) > >>1) Prevent the resizing of views. We are creating simple, "selector" views > Q: By "selector", do you mean that the view contains a fixed list of items? > Selector is not the greatest name. Yes, the item count would be fixed. The space required to show the items would not change. > >>2) Set boundaries on the size of views. > Q: For min size, do you mean that there'd be a minimum size that the view could > be resized down to, but not further? Right. > > Q: For max size, what would happen, would you just end up with empty space in > the workbench? If yes, why is this better than allowing the view to take up > this extra space (seems wasted space in the view is no worse than wasted space > in the workbench). Let's say I have a perspective that is laid out for two side-by-side views. Double clicking on an item in the left hand view brings up a view on the right. Double clicking on another item replaces the existing right-hand view with another. The user may also manually close the right hand view. It's disconcerting to watch the left hand view redraw itself as it expands and contracts for no real reason as views are opened and closed on the right. The view's toolbar and menus also move. Having said this, I'll concede that a max size is less important than a min size. > > >>3) Suppress the ability to minimize and/or maximize a view. > See bug I just entered, https://bugs.eclipse.org/bugs/show_bug.cgi?id=154311 > [Perspectives][ViewMgmt] Need smarter Min/Max view behaviour It sounds like a useful alternative to min/max. > > >>5) Lock a view to one edge of the page. > Can you elaborate why this is required? (I can imagine reasons, just want to > hear real usage cases). > In our case it's just a matter of keeping things relatively simple for users. There are two important, standalone, navigational views that we want our users to always find in the same place, on the left and right edges of the perspective. We want other views in the perspective to be movable and dockable, but they should always stay between the two standalone views.
There are currently no plans to work on this feature. PW
Changes requested on bug 193523
Just fyi: As of 3.4, views may optionally adapt to (or implement) ISizeProvider if they have a preferred size. The default presentation will make a best effort to allocate the preferred size to a view if it is the only part in a stack. If there is more than one part in the stack, the constraints will be disabled for that stack. The size constraints are adjusted for the size of the tab and border trim. Note that this is considered to be a hint to the presentation, and not all presentations may honor size constraints.
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.
