Community
Participate
Working Groups
Build ID: I20070625-1500 Steps To Reproduce: Perspective state isn't saved consistently. 1. Open a perspective 2. Make changes to the perspective (open views, move views around). 3. Close the application 4. Open the application 1. Open a perspective 2. Make changes to the perspective (open views, move views around). 3. Close the perspective 4. Reopen the perspective The two perspectives are not the same. I would expect that if the perspective was closed whether through explicit close or through application close when the perspective was reopened i would expect it to be in the same state.
>>3. Close the application >>4. Open the application I assume you mean shut down Eclipse and then restart it?
yes close and restart eclipse.
If you are saying "reopen the application == the changed perspective but close the perspective and then re-open the perspective == the default for that perspective with no changes" then that is design intent. i.e. that's the behaviour we want. PW
Paul, since the user can reset the perspective at any time, why is it a design decision to effectively reset it on close? What's the harm in us keeping the perspective layout info across closes? I may have arranged it a way I like and would like to keep using it like that, even if I've closed it for some reason (could be by accident, could be to simplify the UI for some task).
(In reply to comment #4) > Paul, since the user can reset the perspective at any time, why is it a design > decision to effectively reset it on close? Because a closed perspective is just removed, there's not such thing as a perspective placeholder ... unless you've saved that perspective, you get it fresh from the perspective factory. Now if you've saved it, when you open it again it will open with that information. PW
Seems like a technical reason why it wasn't done but that doesn't really explain it from the users point of view. It may currently work that way but I don't believe its either intuitive or helpful to the user.
Yeah I kind of have to agree with Chris. :) From the user's point of view, closing the workbench does an implicit save of the perspective, since when I start up again I get it back the way it was. I only ever think of "Save Perspective" in the context of creating a completely different named perspective. But then again, who ever does "Save Perspective"? I never have and wouldn't think to do it in this scenario.
While I'll buy that (it might not be intuitive) it works that way for legacy reasons. i.e. this behaviour was part of the original usecase (for reasons that aren't clear to me). I know I take advantage of it all the time (close all perspectives cleans them all up for me). If someone wants to submit a patch, consider these parameters: 1) there has to be a way to get the current behaviour ... either some flag or maybe tied to the 3.0 vs 3.3 presentation. 2) reset has to work as currently ... it resets to the last "saved" state or the default for that perspective if nothing saved. The PerspectiveDescription has some information ... and then Perspective and PerspectiveHelper (with WorkbenchPage) seem to do most of the work. PW
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
