Community
Participate
Working Groups
build I20040529-0105 - run the browser example, augmented with another view - choose Maximize on the view's tab menu - it has no effect Now that the concept of fixed views has been removed, and the flags are more clearly defined as isMoveable() and isCloseable() (see IViewLayout), we should not combine the maximize behaviour with moveable. See also comments in bug 49811 requesting that these concepts not be combined.
Actually, the problem occurs if the view is in a fixed perspective, but the same argument applies. In a fixed perspectives, all initial views are non-moveable and non-closeable, and the overall layout of the perspective cannot be changed, but that should have no effect on maximize/minimize.
There seems to be a problem with the implementation of ViewPane.isMoveable(). It is currently: boolean isMoveable() { return !page.isFixedLayout(); } It should -only- check isMoveable(IViewReference) on the active perspective. Views that are opened after the perspective is created are moveable, even if the perspective is fixed (but only within the same folder). Also need to double-check ViewStack.isMoveable(IPresentablePart). It should probably just call ViewPane.isMoveable().
Some RCP application end users might freak out when they stumble on the zoom features. It may appear to some that their other views are lost and there may be no real indication (depending on the presentation used) of how to restore the application to it's default layout or unzoom. RCP applications need the ability to turn off or control the zoom functionality. Implementing a perspective as fixed seemed logical. Maybe zooming in a fixed perspective should result in showing that view/editor in a new WorkbenchWindow.
So are you saying that if the perspective is fixed, then minimize and maximize are not supported, but if the view has been marked as non-moveable in a non-fixed perspective, then it still allows minimize/maximize?
Minimize and restore are okay. The maximize/zoom feature, since it hides all views that are not in the zoomed view's stack, pose interesting usability issues, especially for RCP apps targeted at non-technical end users.
I'm not sure on all the details here so correct me if I'm wrong. This is marked as RC2, do we really think we can establish a pattern to fix all the cases in a way that makes sense for everyone. I suggest that perhaps we stand back and think through the scenarios more carefully after 3.0. The question perhaps is whether min/max etc.. can be hidden/prevented/avoided right now and if so we document how that can be done through presentations etc..
deferring till after R3.0
For R3.0, we've made it so that in fixed perspectives, maximize and minimize are not applicable. In a non-fixed perspective, maximize and minimize are applicable even if a view is marked as non-moveable. See bug 65665. After R3.0, we should revisit this and allow maximize and minimize to be separately configurable.
It would also be great to have the possibility to disable editor's maximize command (the same argument: some end users may get lost). Or maybe even the possibility to disable movement of an editor outside its tab group (so that only one tab group can be opened).
any reason why this is marked major? should this be fixed in 3.0.1?
The original problem was marked as major since the behaviour the user saw was unexpected. With the fix for bug 65665, the original problem is no longer seen, so this PR is no longer major. Not action needed for 3.0.1. Changing this to be an enhancement request for 3.1 since I still think apps should be able to override the minimize/maximize behaviour. In order to avoid a plethora of customization flags, it would be better to delegate to the workbench advisor, or allow it to specify a strategy for this behaviour.
Also, the minimize behavior can leave your layout in funny states, and in my applications I would simple like to disable that behavior all together. I would prefer if this was separate from the moveable flag.
Was not able to get to this for 3.1. Another option would be to have global prefs (not necessarily exposed to the user) to control whether minimize is allowed, and whether the minimize/maximize buttons appear in the default presentation.
Reassigning bugs in component areas that are changing ownership.
Over to you...
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.
