Community
Participate
Working Groups
Currently, if additional views are docked in the same space as the intro while it is in standby state (i.e., so there are multiple tabs to switch between), then when the intro is maximized again all of those additional views are also maximized and still available to switch to. Is this the desired behaviour? When the intro is maximized, is there a way to hide the tabs for other views that were opened?
Kim, any comments here?
This is "intentional" insofar that an intro that isn't in standby state is really just a maximized view under the hood.
Perhaps we need to make a list of scenarios that make little sense with the itro view and disable the functionality for it (i.e. prevent the user from getting herself in an unwanted state).
this scenario seems like one that would not be what you would have out of the box, but rather after using the intro, cheatsheets and other views for a while. I agree that it may be undesirable, but would rather not go down the road of making the intro a special case for maximize here. Kim is there any workaround that Dejan can do (close other views in stack etc...?) on intro maximize.
Well, Dejan can't make this happen without acknowledging that intro is implemented as a view and we don't want to have that happen. If anything is to be done, we'd have to do it. We could certainly close other views on the stack, but I don't recommend this. Killing a users views is much more invasive than simply leaving the tab there.
We went down the path of 'special' status for IIntro part and we must go all the way. Julian reported that he was able to get into a fairly stupid state by stacking, detaching and docking the IIntro part in a standby mode. Somehow the underlying view implementation in combination with some 'special' code for the IIntro part produces unwanted outcomes if we are not careful.
Dejan, what you're describing sounds like a bug in the "sticky" or fixed view support. Please report it with the steps in a new bug.
This can happen out-of-the-box when one starts with a 2.1 workspace.
I'm not sure it can happen out of the box as the intro view is opened in its own view stack on the right hand side of the perspective. Christof have you seen this?
Yes, I started 3.0RC1 with a 2.1.3 workspace in the default Java perspective and the Intro view was stacked with the Task view. The Task view was afterwards centered at the bottom. I have an untouched copy of that 2.1.3 workspace in case you need additional information.
*** Bug 89702 has been marked as a duplicate of this bug. ***
ping... any thoughts on this one? Can Intro have its own folder in the perspective and no other view can be placed with it?
Hmm.. not for 3.1? :) I'm sure this is doable, but not a this stage.
I think this falls under Platform UI.
Remy is now responsible for watching the [ViewMgmt] category.
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.
