Community
Participate
Working Groups
http://download.eclipse.org/e4/sdk/drops/I20100616-2127/index.php. The views no longer have a context menu. This makes it impossible to - turn a view which is inside a group/stack into a fast view - close a not yet created view which is hidden inside a group/stack
>- turn a view which is inside a group/stack into a fast view Looks like the concept of fast views itself is gone, correct? If so, the ability to close without creating a view would be the only lost functionality.
Increasing severity again: actually I miss the functionality to turn a view out of a group into a fast view quite a bit.
Dani, you can minimize a stack and gain back most of the legacy 'fast view' capabilities...
>Dani, you can minimize a stack and gain back most of the legacy 'fast view' >capabilities... Not really: I can't close a view from that minimized list which is important for performance: after a restart I'm now forced to create the view before I can close it. Also, my main point is that I cannot quickly make a view from a stack into a fast view - it's all or nothing.
I'm not sure we can address this (directly) before release but I'll tag it for RC1 so we can triage it tomorrow...
Dani, sorry but with the number of other issues that *have* to be addressed this just doesn't make the list for the 4.0 SDK release. At worst it's an inconvenience that you have to put your 'fast views' into a stack and then minimize it, not a complete loss of functionality / crash (as are some of the remaining issues.
(In reply to comment #0) > - close a not yet created view which is hidden inside a group/stack You should be able to do this in the next build with the closure of bug 313328 and bug 325722.
'Close' is now there but all other items are still missing. Also, the menu is still not there when the view is a fast view.
(In reply to comment #8) > Also, the menu is still not there when the view is a fast view. That's covered by bug 317208.
Also see bug 203849 - that change in that bug will need to be propagated into 4.x.
*** Bug 365743 has been marked as a duplicate of this bug. ***
Paul, Eric: this is still one of the bugs that makes me love 3.x more than 4.x.
Is this bug now about most of the missing tab entries, or the ability to turn one view into minimized view on its own? PW
(In reply to comment #13) > Is this bug now about most of the missing tab entries, or the ability to turn > one view into minimized view on its own? > > PW Well "now" it is about the missing entries - at the time I filed the bug it was both, but now there's already a context menu with 'Close' (see comment 8). What I miss most from the 3.8 items is: 'Fast View'. Actually, I never used any other item. However, I could imagine that for keyboard users the resize and min/max items might be useful.
This is a major productivity killer for me: e.g. start a new workspace and try to make the Problems view a fast view - it's not possible directly. One has to do this is: 1. move it out of the stack and make sure it doesn't end up in another stack 2. minimize the whole stack And since I cannot make the view itself a fast view, I end up with two icons for each of my fast views (the view icon and the minimized stack icon). Can you please reconsider to fix this for 4.2?
Conceptually what is still missing compared to 3.x: - Ability to minimize and restore individual views independent of their stack - Ability to drag a part into the trim to minimize it, and drag out of the trim to restore - Ability to add a part to a minimized stack - Button in the trim that has drop-down menu to make a view into a fast view I think having distinct concepts of "fast view" and "minimized view" is too confusing so I would suggest consolidating remaining functionality around the minimize/restore/maximize concept. Also note that since editors can also be minimized I wouldn't want to start talking about "fast editors" as well. The word "minimized" actually conveys more useful information than "fast". Overall I think we are close on this - we can represent all the possible shapes, we're just missing the user options to get where they want to go: 1) Command on part context menu to minimize the part independent of its stack 2) Command on minimized part context menu to restore individual part 3) Ability to drag part into and out of trim, including into minimized stacks 1 and 2 sound feasible for 4.2.1. Maybe 3) could be pushed to 4.3 if too complicated.
I'm fine getting rid of the term "Fast View". What's important to me, is that the minimized view only appears as view button in the trim i.e. without the additional waste from the stack around it. Also missing: 'Orientation' context menu on minimized view. 'Detached' toggle on "normal" view and detached view From those two I use the first one often, but never the last one as I don't work with detached views.
I just started using eclipse 4.2 and I also miss the so called 'fast view'. At first I did not even realized what's wrong because I went to the preferences (General -> Perspectives) and chose Open a new view as fast view (the option is still available as it has always been). Then I went to open a new view and ... surprisingly it does not want to be a 'fast view', but opens in an existing group. So what happens to this preference now?
I'm in the same boat with the 'Fast View' change. I used to mark every view as a 'Fast View', some with horizontal and some with vertical orientation. I took this concept from a blog about maximizing editor space while being easily accessible to the tools you need and I loved it. I just upgraded to Juno and this was the first thing that stood out as missing/wrong to me. I tried using the minimized stacks, but clicking on a view from those stacks was very, very sluggish (seconds to restore) and appeared oddly, and wanted to consume real estate rather than automatically minimizing after losing focus. This alone is enough that I'm reverting to 3.7.2 until I hear positive news or I can take time to develop a better personal setup within the new architecture.
(In reply to comment #19) > This alone is enough that I'm reverting to 3.7.2 until I hear positive news > or I can take time to develop a better personal setup within the new > architecture. You can put each view into its own stack and then minimize that stack. Then use Drag & Drop to to size the fast view to your liking.
Yes you can setup 4.2 in the same way as 3.x, it's just missing some of the convenient commands and gestures for doing that setup. I think comment #16 summarizes the current missing commands/gestures.
(In reply to comment #19) > This alone is enough that I'm reverting to 3.7.2 until I hear positive news or > I can take time to develop a better personal setup within the new architecture. I should also add, thank you for taking the time to give feedback. There are a lot of possible things to focus on, so knowing these concrete pain points that are high value to fix is very useful.
I'll second John's comment about thanking everybody for their feedback. I'll address a few of the comments here and see where that leaves us... @Sylvia, I've opened bug 387291 to ensure that we clean up stale references to 'Fast View' prefs. Also, note that if you have the editors maximized then new views will automatically be added to one of the existing trim stacks. @David, the sluggishness you mention is *not* a function of having the view in a minimized stack. Also, while I admit we still have performance improvements to make I've never experienced 'seconds' to bring up a view (whether minimized or not). Are there repeatable steps I could use to reproduce this ? It might help our optimization efforts... @John, 1) Command on part context menu to minimize the part independent of its stack The only way to do this would be to make a new stack , add the view to it and minimize the stack. 2) Command on minimized part context menu to restore individual part To where ? 3) Ability to drag part into and out of trim, including into minimized stacks This is covered by something that I'd love to be able to get the time to work on...'open on hover' which would auto-open a minimized stack during DnD operations (a la the Task Bar in windows).
Adding back the concept of 'orientation' seems like a good idea though since we know that we will have stacks that have views which differ in their preferred display requirements. Actually this information could also be used to affect the initial stack selection when the view is opened (i.e. it could choose 'bottom' if it's horizontal and 'left' if it's vertical...). Were we to want to restore the complete 'Fast View' paradigm we could likely do so; provide a 'magic' minimized, non-restorable 'Fast View' stack with an id that would allow us to locate it when needed. Unfortunately we don't have the resources to devote to this. At this point I'd be far happier seeing what performance improvements we can accomplish. The amount of time that someone spends setting up their perspective is a small percentage of the overall time spent in the product so needing to manipulate the stacks themselves and then minimize the ones you want cannot be a 'productivity killer'. We also have a plan to address the major issue here, needing to re-arrange the UI for every new Workspace, surely this would be time well spent (even if the initial arrangement took a little extra time at least you'd never have to do it again...;-).
(In reply to comment #24) > The amount of time that someone spends setting up their perspective is a > small percentage of the overall time spent in the product so needing to > manipulate the stacks themselves and then minimize the ones you want cannot > be a 'productivity killer'. I strongly contradict to the last statement. I often close some views when no longer needed (e.g. 'JUnit' view) and at that point this bug hits me when the view is shown again and I want to make it a fast view. Another problem is the wasted space because each fast view has to sit inside a stack with visual clutter. > We also have a plan to address the major issue > here, needing to re-arrange the UI for every new Workspace, Do you have a bug number for this work? Is it planned for 4.2.1?
Dani, there may be a way to get close(r) to the old fast view style of things. Make a stack and populate it with anything that you would normally make a fast view. Minimize it. Now if you close a view that was in the stack and subsequently re-open it it will re-open in the stack it was in (i.e. as a fast view). This makes this approach even better than 3.x since you don't have to do anything. The only time you would 'restore' the stack is when you need to add some more views to it (then minimize it again). Since the stack is usually minimized it'll act very close to the legacy fast view behavior (I'll be adding some handling for the orientation shortly). I haven't opened a defect for the UI separation yet because I'm still figuring out what the scope of the feature would be. For example it'd also be capable of being able to have multiple layouts based on the number of displays available. This would help for folks that have a laptop that they used both docked (multiple screens) and non-docked (only one screen). This work will have to wait until after the SR's go out I think...
(In reply to comment #26) > Dani, there may be a way to get close(r) to the old fast view style of > things. > Make a stack and populate it with anything that you would normally make a > fast view. Minimize it. Now if you close a view that was in the stack and > subsequently re-open it it will re-open in the stack it was in (i.e. as a > fast view). This makes this approach even better than 3.x since you don't > have to do anything. The only time you would 'restore' the stack is when you > need to add some more views to it (then minimize it again). Thanks, but obviously, you did not test this. When the last view of a minimized stack is closed, the stack also goes away. Next time that same view is opened it opens "normal" and not in a minimized stack. Also, I do not want to waste screen real estate with an empty stack or a stack with a dummy view that I never use.
(In reply to comment #26) > Dani, there may be a way to get close(r) to the old fast view style of things. If the only thing different between a minimized stack and fast views was that missing drag support (bug 384240) that wouldn't be bad. Unfortunately, there are more glitches: bug 384814, bug 386914, bug 386828, bug 385853, bug 385318. I guess what Dani observed in comment 27 would be another one.
The idea that a minimized stack becomes un-minimized when it goes empty seems like a bug to me, there's no real reason that I can see that this should be necessary (it should of course hide the trim stack). Tomasz, in reality I'd prefer to be working on some of the defects you mention than trying to bring back the complete FV functionality *at this time*. For now I'm going to do two things: 1) add the ability to flag a view as horizontal / vertical and adjust the screen use of the fly out composite accordingly 2) Check to see what happens if I don't restore a minimized stack that goes empty.
Looks good. The only thing I noticed is that trimStackMenu is created when trimStackTB is, but it is never disposed. Is that because when the trim stack is disposed it will be cleaned up automatically? If so, it should probably be nulled out in the dispose listener in org.eclipse.e4.ui.workbench.addons.minmax.TrimStack.updateTrimStackItems() just like trimStackTB. Unrelated to that, it looks like updateTrimStackItems() is called from multiple event handlers, adding that dispose listener every time (a leak of listeners, as it were). Should that listener be moved to where the trimStackTB is created? PW
commit f92afae8eda2454a30b4b798ca929c2dbd63a6dd Added orientation menu elements to the minimized trim stacks (for part stacks only). Also forces the fly out to fit within the current client area (used to clip it) as well as fixing a possible dispose listener issue. I'm going to move this defect to 4.2.2 for now and see if I can get the minimized stacks to stay minimized there.
(In reply to comment #31) > commit f92afae8eda2454a30b4b798ca929c2dbd63a6dd > > Added orientation menu elements to the minimized trim stacks (for part > stacks only). > > Also forces the fly out to fit within the current client area (used to clip > it) as well as fixing a possible dispose listener issue. > > I'm going to move this defect to 4.2.2 for now and see if I can get the > minimized stacks to stay minimized there. It "works" but the selected choice (vertical or horizontal) should have a bullet and not a check mark - the current UI is misleading.
Pushed some improvements to the menu: 1) Added orientation submenu, added 'default' orientation (no presentation hints), options are now radio buttons 2) Added 'restore'. For now this restores the whole stack, but could be replaced with equivalent to the old 'Fast View' checkbox to only restore the selected view. 3) Added mnemonics. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=68e0e94fffb2d7ce9739bba81e67cfe4a51c1a43
(In reply to comment #33) > Pushed some improvements to the menu: > > 1) Added orientation submenu, added 'default' orientation (no presentation > hints), options are now radio buttons What is 'default? Is it really needed? > 2) Added 'restore'. For now this restores the whole stack, The action is on each view and hence it should also activate that view. > 3) Added mnemonics. How do you bring them up? The system menu (Alt+-) seems not to work in 4.x.
(In reply to comment #34) > What is 'default? Is it really needed? Quick views start with a default layout which is the corner of the window (looks like half of window width/height). So the initial orientation isn't horizontal or vertical. I think the default layout is useful enough to justify the option in the menu. 2) Added 'restore'. For now this restores the whole stack, > > The action is on each view and hence it should also activate that view. > Fixed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=521def6b9597db6acaf013f761fa0a45c1ed839c 3) Added mnemonics. > How do you bring them up? The system menu (Alt+-) seems not to work in 4.x. On linux the menu mnemonics are visible by default. I think on windows you can make them show up be default in accessibility options: http://superuser.com/questions/16952/how-to-enable-underscore-shortcut-mnemonics-for-menu-items Shift-F10 opens the context menu with mnemonics for whatever has focus. However, the minimized part never has focus.
Fast view support has been removed a while ago.
