Community
Participate
Working Groups
Steps to reproduce: (1) Open the IDE (2) Open a secondary window via Window -> New Window (3) Open a view that is not open yet, e.g. JavaDoc (4) Close the secondary window by the [x] in the window decoration (5) Open a secondary window via Window -> New Window again EXPECTED: the view opened in (3) is there ACTUAL: the view opened in (3) is not there Is there maybe a way to store the view in the perspective definition, so that it is always there when a new window of the given perspective is open? The only workaround I have found is to never close windows by the [x] in the window decoration. Only when I close all windows at once via File -> Exit, both windows are correctly restored when I open the IDE next time.
Seems like the state (memento) of the 2nd window isn't persisted.
Related to bug 514935?
(In reply to Andrey Loskutov from comment #2) > Related to bug 514935? It doesn't seem to be the same story, but maybe some patches for bug 514935 positively affected the reported story. We should try it with an integration build.
I tested the fix for bug 514935 in the I20171210-2000 integration build and it does not improve the problem reported here. At a first glance the problems seem unrelated.
It is a *new* window. If you want to keep the state you need to save the perspective and then use Window > Open Perspective.
@Dani: one thing I don't get with your answer is the following use-case: I'm from my main view on a perspective that's heavily modified with new view, one less view stack and so on. I do "New Window" and I got a new window (fine), with the same perspective (why not, but I think it was chosen because it's the default one of my product, not the current one from "caller" window), but the perspective in the new window has different content than the one in my current window. I would expect at least the state of the perspective to be saved and shared between both windows. Shouldn't it be the case? Or each window has it's state for each perspective (in which case it wouldn't harm to store the one for new windows as well)?
(In reply to Mickael Istria from comment #6) > @Dani: one thing I don't get with your answer is the following use-case: > I'm from my main view on a perspective that's heavily modified with new > view, one less view stack and so on. I do "New Window" and I got a new > window (fine), with the same perspective (why not, but I think it was chosen > because it's the default one of my product, not the current one from > "caller" window), but the perspective in the new window has different > content than the one in my current window. > I would expect at least the state of the perspective to be saved and shared > between both windows. Shouldn't it be the case? Or each window has it's > state for each perspective (in which case it wouldn't harm to store the one > for new windows as well)? The 'New Window' command is limited (there are bugs). It takes the current perspective and then opens a new windows with the *saved* state of that perspective. So, even if you rearrange stuff in the original window it won't reflect that. I'd rather change that than opening a *New* window with already saved state.
> It is a *new* window. If you want to keep the state you need to save the perspective and then use Window > Open Perspective. Saving the perspective is a good workaround. Thanks for mentioning it, I was not aware that I can save the current perspective under the same name. Although your suggestion helps, I still find the behavior described in the original report wrong. Closing the secondary window and re-opening it again should bring the secondary window in the same state as when it was closed. > I would expect at least the state of the perspective to be saved and shared between both windows. I'd find this OK when opening the secondary window for the first time, but once the secondary window got its views re-arranged, it should be able to store them on close and re-store them on re-open.
(In reply to Peter Palaga from comment #8) > > It is a *new* window. If you want to keep the state you need to save the perspective and then use Window > Open Perspective. > > Saving the perspective is a good workaround. Thanks for mentioning it, I was > not aware that I can save the current perspective under the same name. > > Although your suggestion helps, I still find the behavior described in the > original report wrong. Closing the secondary window and re-opening it again > should bring the secondary window in the same state as when it was closed. > > > I would expect at least the state of the perspective to be saved and shared between both windows. > > I'd find this OK when opening the secondary window for the first time, but > once the secondary window got its views re-arranged, it should be able to > store them on close and re-store them on re-open. What if you inovke 'New Window' 10 times from the same original window (while keeping them all open)? It's not practical to deal with such state and it is not OK to propagate changes made in the new window(s) back to the original.
> What if you inovke 'New Window' 10 times from the same original window (while keeping them all open)? I'd expect every n'th window to re-store the n'th state when I re-open it. > It's not practical to deal with such state Not practical for whom? - I find it definitely practical for users. If somebody happens to have 10 screens why should we not allow him to store 10 window states? > it is not OK to propagate changes made in the new window(s) back to the original. I am not asking for that.
As auser, I would have the same expectation as Peter regarding behavior of new windows.
(In reply to Peter Palaga from comment #10) > > What if you inovke 'New Window' 10 times from the same original window (while keeping them all open)? > > I'd expect every n'th window to re-store the n'th state when I re-open it. > > > It's not practical to deal with such state The state is preserved on restart but not for opening the next New Window. Going back to the 10 windows example. Assume we store the (different) state for each of them. Then you close a few. At some later point you open a New Window again. Which window's state should it use? The first? The last? The last active?
(In reply to Dani Megert from comment #12) > Going back to the 10 windows example. Assume we store the (different) state > for each of them. Then you close a few. At some later point you open a New > Window again. Which window's state should it use? The first? The last? The > last active? That's a good question! I have the impression that the multiple window supports works but that the typical usages are not identified/defined so they are not supported. The question you ask here is a good example where I think something needs to be decided, according to some experiments and feedback. Another one would be "what happens if I open a new window, work on it, close the initial window and then restarts? Is the state of the new window used when restarting?". Some typical issue seem to be that for instance, in case of a new window, what should the "File > Exit" do: exit application (close all windows) or just close the window (so it could be retitled). It also looks like we are missing a clear "Close current window action" when there are multiple ones. The UX for multiple windows seem to require a full (re)design by taking into account user expectations.
> At some later point you open a New Window again. Which window's state should it use? The first? The last? The last active? The n-th window should use the n-th saved state if the n-th saved state exists. Otherwise it should either copy the state from the current window or use the current windows perspective default (I have no clear pref).
(In reply to Peter Palaga from comment #14) > > At some later point you open a New Window again. Which window's state should it use? The first? The last? The last active? > > The n-th window should use the n-th saved state if the n-th saved state > exists. Otherwise it should either copy the state from the current window or > use the current windows perspective default (I have no clear pref). Well, yo don't know "n" if you go back to the original window and invoke New Window. What I tend to agree is that it should open the new window with the state of the original window, even if changes have been made compared to the stored perspective. Everything else would contradict to "New" for me.
(In reply to Dani Megert from comment #15) > What I tend to agree is that it should open the new window with the state of > the original window, even if changes have been made compared to the stored > perspective. Everything else would contradict to "New" for me. @Peter: would that already be a good step forward for your original user-story? Would it help?
> Well, yo don't know "n" if you go back to the original window and invoke New Window. No, n can be defined as equal to the number of currently open windows plus one. > What I tend to agree is that it should open the new window with the state of the original window, even if changes have been made compared to the stored perspective. Everything else would contradict to "New" for me. No, it does not contradict "new". New windows (unlike new documents) may come up with some state and history. I am not sure if the proposal to always open the new window with the state of the original window (and further not (re)storing the window state on window close/re-open) would be a step forward. I rather do not think so. It would make it impossible to keep two distinct view arrangements for the same perspective. This whole topic matters to me since I started using multiple monitors. It is a huge usability win to be able to have two windows on two separate monitors with the same large project focused on two distinct locations. Say in win1 I have some backend module's package open in Project Explorer and a few Java files from there whereas in win2 I have the related integration tests that live in the same git tree but in a different module that happens to be quite far away from the backend. The back and forth coding in two windows works very well in Eclipse. The only thing I complain about here is closing and restoring of the secondary windows. When I use File -> Exit in the evening, all is fine because my two windows get restored next morning as I left them the day before. Once I forget to use File -> Exit and close any windows through the [x] in its decoration all my view arrangements are lost and I have to spend some time restoring them manually. Has anybody of you ever used multiple windows on multiple monitors to code a large multi-module project? Please try it and try to think of what would be the natural behavior for the secondary windows.
(In reply to Peter Palaga from comment #17) > Has anybody of you ever used multiple windows on multiple monitors to code a > large multi-module project? I'm personally not using multiple windows as I like to keep the amount of windows minimal (it's already hard to find the right tab, but the right tab in the right window becomes a nightmare to me!) FYI, I believe that most people following this thread are used to large multi-modules project and have the whole Eclipse Platform code-base in their workspace and found workflows that suit them well with a single window. It really becomes very personal at some point, and it's very probable that the workflow you have isn't used by other contributors so isn't likely to become top-priority for them. > Please try it and try to think of what would be the natural behavior for the secondary windows. In this kind of situations, it's hard to add work into committers bucket and expect them to do it, as they're all busy with other things. So unless you manage to convince anyone that this is highest-priority (which is hard), you shouldn't expect nor require too much effort from committers at the moment. What I recommend is to drill down the issue into finer-grain tasks and smaller simpler enhancement/fixes. Small pieces of work are usually more efficient at being considered by busy committers. I also suggest that when you get such an answer that may sound negative from committers, you just skip the negative pieces and focus on the positive parts and the related proposals/trade-off. It's very frequent that the feedback given by Dani or others sound very negative at the beginning but progressively drives towards identifying small pieces of work that provide most of the value on short-term, and a better way to create more value on long-term. > It would make it impossible to keep two distinct view arrangements for the same perspective. Different view arrangements == Different perspectives ;) It seems like the perspective is an important concept technically in this workflow. With Dani's proposal which -if I understand correctly- consists in keeping perspective content in sync across windows, then it becomes more obvious to users that is they want different view arrangements, they have to go through different perspectives. From there, we may be able to find out some small menu additions so that when users understand it's all about perspective, they understand better how to create a new perspective and reuse it in new windows.
(In reply to Peter Palaga from comment #17) > > Well, yo don't know "n" if you go back to the original window and invoke New Window. > > No, n can be defined as equal to the number of currently open windows plus > one. Yeah, you can define it like this but it's similar to random because the user would not know what happens. > Has anybody of you ever used multiple windows on multiple monitors to code a > large multi-module project? Please try it and try to think of what would be > the natural behavior for the secondary windows. Yes, I do. But I rarely have to open a new window. I have my setup and all perspectives I care about are stored, so that I can easily open them via Window > Perspective > Open Perspective if needed. I think you should try the following preference on the 'Perspectives' preference page: Open a new perspective (o) In a new window And I guess a new feature like "auto-save perspective" would help.
> Different view arrangements == Different perspectives ;) I was counting seconds when somebody comes with this statement and I have my answer ready :) When working in the single window mode, I do not need to store perspectives manually. Their states are stored on workbench close and are perfectly restored on workbench re-open. My expectations for secondary windows are the very same. By asking others to use multiple windows I did not want to dictate anyone's daily schedule. Sorry if it was perceived in that way. My general intent was to make others aware of the fact that the multi-window set up can be used for a very useful thing. I know frustratingly well what I can expect from a community project and I know quite well where I can pay and be treated as a customer.
(In reply to Peter Palaga from comment #20) > > Different view arrangements == Different perspectives ;) > > I was counting seconds when somebody comes with this statement and I have my > answer ready :) That because deep inside yourself, you know how true this is :D > When working in the single window mode, I do not need to store perspectives > manually. Their states are stored on workbench close and are perfectly > restored on workbench re-open. My expectations for secondary windows are the > very same. As far as I understood of Dani's hints, the idea would be to have the same perspective in different windows share their state. So updating on one window would also update in the other windows using that view. As a consequence, user would feel that the right way to have multiple arrangement is to have different perspectives and use different perspectives in each window. And the cool thing if we rely on perspective is that their state is already persisted and stored, so there wouldn't be anything else to store to better support your use-case.
(In reply to Mickael Istria from comment #21) > As far as I understood of Dani's hints, the idea would be to have the same > perspective in different windows share their state. So updating on one > window would also update in the other windows using that view. No, definitely not. That would be horrible.
