Bugzilla – Full Text Bug Listing
| Summary: | [FastViews] Create Multiple FVB's | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Eric Moffatt <emoffatt> | ||||||||||||
| Component: | UI | Assignee: | Eric Moffatt <emoffatt> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P3 | CC: | bogofilter+eclipse.org, bokowski, bpasero, daniel_megert, eclipse, ed.burnette, ekuleshov, john.arthorne, julianj, kelvinc, Kevin_McGuire, Konstantin.Scheglov, lindawat, markus.kell.r, max.gilead, Mike_Wilson, mlists, nboldt, pombredanne, schtoo, thfin, Tod_Creasey, wbeckwith, wmitsuda | ||||||||||||
| Version: | 3.3 | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Windows XP | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Bug Depends on: | 176506, 63214, 63385, 124942, 154921, 155537, 155539, 157872, 158474, 158520, 158569, 158658, 158709, 158711, 158712, 159750, 161263, 161312, 162534, 163826, 163828, 163992, 165872, 166455, 167181, 167432, 168399, 168890, 170122, 172559, 172708, 174487, 176108, 176408, 176693, 176845, 176847, 176848, 177150, 177181, 177196, 177200, 177517, 177518, 177850, 177905, 178197, 178520, 178521, 178788, 178791, 178798, 179702, 181729 | ||||||||||||||
| Bug Blocks: | 154120, 171399, 169602 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Eric Moffatt
Created attachment 47949 [details]
Multi FVB patch (work in progress)
This is a temporary patch to allow checking on Linux/Mac
Created attachment 47960 [details]
This is a patch of the code that I'm committing
This is just in case we need to reverse this.
I've committed (in >20060815) code that will act as a starting point for investigating the use of multiple FastViewBars (FVB's) in the workbench. Note that it's still a bit fuzzy on the edges but works well enough to generate the feedback that I need to flesh it out and polish it... In order to use this you'll have to define "-DMultiFVB" as a VMArg. This will cause a new context menu item "Move to Trim" to appear on the view stack's context menu. Note that even if not defined the default FVB behaviour has been modified so please let me know if you see anything inconsistent with the existing behaviour. In this incarnation I've introduced the ability to create a 'Trim Group' out of an existing view stack. A trim group differs from a normal FVB in that it acts as a simple collection of view references that can be either restored to the workbench or moved back into the trim group using a single click. You can also drag views into an existing group. This allows some fairly flexible handling. For example, you could create a group containing all your views except the Outline View. Now you have a (somewhat...;-) smart 'maximize editor'; collapsing the group will free up gobs of space for the Editor Area without having to maximize the editor itself (handy if you're doing compares) while still allowing access to all your views as fast views. At this point all I've really done is to clean up the current implementation to support multiple, perspective-based FVB's and implemented the trim group behaviour in order to have a test platform. I expect that there will be many uses for these once the base functionality is in place (i.e. one current suggestion is to automatically create/delete groups for every stack if the Editor is zoomed / restored, allowing access to your views even when the editor is maximized with out having to restore it). We have a new lever, we just have to figure out what to move with it... Caveat 1: Boris has just finished breaking this in two ways: The 'Close' button looks like it works but leaves a stale group around Restoring a view in a group using the 'Fast View' menu leaves the WB in a state where it's confused about whether or not the view is 'fast'. OK, I've committed (in >20060816) code that fixes a major defect when switching perspectives after closing a trim group (stale listener leading to NPE's) and also won't leave cheese when closing. These fixes should be in today's n-build. Also, I've committed (in >20060817) code the new groups now dock on the most appropriate side and use the display orientation (horiz / vert) based on the original stack's position/size. This will be in tomorrow's build. I'm about to start on seeing if I can whip up a test replacement for the 'zoom' (aka 'maximize') that will automaticallly create a group for each stack on maximize and restore/delete them on 'unzoom'. Again, these are simply test scenarios to spark ideas about how we can best leverage the new capabilities (suggestions are not only welcome but necessary...;-). Also, just to capture some of the enhancements that need doing: The 'Fast View' menu entry should read 'Collapse'/'Restore' for views that are in a group and work accordingly. The User should be able to define the 'type' of new FVB they want (old-style or group) during the definition phase (perhaps 'Move to Trim' would be a cascade that has 'as Fast View Bar' and 'as Trim Group' items). Using the 'Move to Trim' command on a view (it should be able to handle single views)/stack that contains view refs that are already in a group should collapse them back into their group rather than creating a new one. Tightened up the code to work with the RCB test suite (i.e. FVB's turned off and/or workbench oeveridden...). Committed in >20060817.
Committed in >20060820. You should pick up this built ASAP, it's much more stable...
I've just added the first cut at over-riding the minimize/maximize behaviour. The new behaviour is:
Minimize == move to trim
Maximize == move averything -but me- to the trim
An interesting side effect of this is that neither operation changes the current IPresentationState of the workbench...there is no need for either a MINIMIZED or MAXIMIZED mode; only different presentations of the view stack ('in workbench' or 'on trim').
The only issues I've noticed are:
- the mazimize button doesn't get changed to 'restore' when 'maximized'
- maximized view stacks don't expand to occupy the extra space
Both of these are the result of the WB having an expectation of being in a particular 'mode' before behaving correctly (As Tesler said "Don't mode me in"...;-).
We -will- have to discuss this since the modes are public API, defined in IStackPresentationSite.
Created attachment 48255 [details]
Capture f changes necessary for 'smart' min/max
Want to capture this since it'll certainly have to be massaged to fir the current API story...
Adding related defect... Note: if you have taken an integration build to try this out, you will need to add "-vmargs" to the command line (ie. "-vmargs -DMultiFVB"). This is very cool. Some comments, based on *very brief* experimenting with the 0829 integration build: 1. I find the use of the collapse view stack control to be the natural metaphor for creation of the trim group. It just feels "right"! 2. The trim group has little controls for expand and collapse. I find the collapse button to be unnecessary now that you've tied into the existing view stack expand/collapse. This assumes a workflow where one trim group = one view stack, which I assume is where we're going. To collapse the trim group, I use the collapse button in the view stack. 3. As an aside, you could never fit two controls side by each in such a small space; its pretty challenging hitting the expand for the trim group. 4. Once a view is in the trim group, I find it then odd that clicking on it made it act as a fast view. I was expecting it to be restored to the layout of the workbench, perhaps because that's the "restore" corollary to the collapse metaphor, whose control I used to create the trim group. 5. I am not sure if I'd actually *want* to just restore a single view from the trim group. I think I am primarily looking to do this to do a more usable minimize of the view stack. 6. There may be work modes where I move the view stack to the trim and then expect to be able to get at the views as fast views. My inclination would be though to say that fast views and view stack min to trim are separate. 7. In my current work pattern of the trim group acting as the "min'd" view stack, I have no need for the close box. That is, the trim group is only there to restore the view stack. Once expanded it could actually disappear from the trim, although this might not be a good idea for a number of reasons (trim width change/redraw being one of them). Basically, I think this shows promise, and now we need to just decide exactly what its purpose is, which use patterns we wish it to support. Is it just an custom place to put fast views? Is it representative of a min'd view stack? etc. Committed in >20060906. Sorry for the delay in capturing (most of) the feedback but I've been digging into the animation engine for most of the week. OK. This is a much 'cleaner' version...I'm in the process of removing most of the 'Fast View' GUI... - There are fewer choices on the context menu for views in the trim (should really only be "Close" and that's up for discussion...;-) - No more view Dnd either into or out of trim stacks (FVB's) - No more Restore/Collapse behaviour; there's just a 'Restore' icon (a la the 'standard' restore button on View Stacks in the old behaviour. WARNING: The new animation code is certainly broken and may also be broken on Linux. Shouldn't fail but it turns out that the behaviour of the SWT image code I'm using is platform dependent...you may want to turn off animations on these platforms... Kevin, I think that the new code addresses most of the issues in comment 12 (1,2,3,5). The remaining issue is the introduction of 'Fast View' as a necessary concept to clients who may not use (or even hate) the current Fast View behaviour. You may not believe this but I'm now buying it...;-) The killer was the -necessary- part. A new user is likely to live quite happily without ever knowing about FVB's so why shove them in their face? I was confused because I'd started out producing Multple FVB's (see the defect title) and just 'backed into' the Min/Max as a use of the new functionality. No problem, I still have to provide multiple FVB's but it's only a new menu entry away now..;-). For Min/Max I think your concept of a simple piece of trim, identified by the View refs it contains (we should show the individual View Names as ToolTips...) but otherwise simply acting as a 'restore' button works fine. The question of whether or not it disappears is interesting; if it stays in the trim how does the User get rid of it? On the other hand using the same pointer location to Opem/Close the stack is really nice for quick looks...for now I'll make them go away (which is no worse than the current behaviour). Now, back to the Multiple FVB's...my current idea is to change the change the current "Fast View" command to "Add to Fast View Bar" and make it a cascading menu. Just selecting the entry (without opening the cascade) would add it to the 'global' FVB (i.e. the one we have now) but the cascading menu would allow adding it to a particular FVB as well as to a "New..." FVB. We can do image tricks or owner draw (Tod?) to show the view icons in the menu (since that's how users identify stacks). The operation should work either on a particular view or on he whole stack and work like the minimize behaviour except for the resulting trim control... I'll still need some affordance to get rid of them (see the previous comment). Although I am more from the bug 88239 side of things, I really like what I get with the multi FVB approach (In N20060911). - minimize to FVB makes sense. One way of minimization is enough. We need no differentiation between (old) minimization and minimization to FVB. However, the FVB should evolve to support textual rendering in the end, or even a tab metaphor, which would again be close to the mock in attachment 18965 [details]. - not sure whether the user expects a complex menu structure as proposed in comment 15 to select the FVB to minimize a view to. For most views it should be fairly simple to find out where to minimize them to: they would collapse along their longer edge and form a new FVB if none exists there. This would mean that FVBs can exist even between any parts, not just along the workbench edges - but perhaps this is too complex. - the minimize animation works under linux (Fedora 5), but only after blocking the entire UI for a second or two. - I don't see the use of the restore button on the FVB. If I decide that a view should remain visible, I can always convert it to a non-fast view. Other UIs call that to "pin" a view or to "make it sticky". I don't think I ever want to pin all views on a FVB at a time. Alternatively, if restoring a minimized view follows the tab-style, it would restore the entire FVB to a view stack, similar to the side pane in Acrobat Reader. Tom, thanks for the feedback. We've been going over what 'options' should be available in this area. It's been decided that we'll need some way to support the 'old-style' min/max in some manner just to quell backlash from folks who may already have useage scenarios relying on it (sigh). My current plan is to have three 'options': 1 - Maximize using minimize 2 - Minimize to trim 3 - Use Fast View behaviour when minimized (requires 2) NOTE: I'm putting quotes around 'options' because there is still an open discussion as to where to expose these (Pref page, in API (WorkbenchAdvisor?), using a new Presentation?). Thanks for the update on the animations. I'm still working on these and have opened SWT defect 156445 to cover a similar delay on Macs. It may be that I'll have to remove the 'backing store' from the current approach but I find it hard to believe that we can't capture a snapshot of the main workbench window in <10 millisecs today). Nice to see some other's commenting(https://bugs.eclipse.org/bugs/show_bug.cgi?id=153957#c16). The interesting question for the community seems to be: If I now get a FVB through minimization of the view stack, and if in that collapsed form the views act as fast views, do I ever need to be able to individually/explicitly create a fast view? It would be nice to have a single, simple metaphor for real estate management. With regards to Tom's comments, there is certainly an issue around the FVB being clearly representative of the collapsed views. The icons for the views may not be sufficient. However, I don't know if we'd see the vertical text as shown in the mockup, mostly out of concern around clutter of the desktop trim edges (there's not a lot of real estate to go around there). (In reply to comment #18) > It would be nice to have a single, simple metaphor for real estate management. I've suggested on the other issue to make quick views also work like detached views, so you can resize and move them around more flexibly (including having multiple floating view active at the same time). Then it would be all consistent - you could minimize to quickview bar or when detached use quickview bar for the access. (In reply to comment #19) >>I've suggested on the other issue to make quick views also work like >>detached views I don't quite understand the suggestion, could you please elaborate? Quickviews have the quality that they are extremely temporary: 1. you open it 2. you scroll through it 3. you select something 4. it immediately goes away Detached views have a very different temporal quality (the same as regular view, its just they get their own child shell) and thus different usage. Do you simply mean the detached views should be dockable to the FVB? For example, you could do something along the lines of the following?: o Tear out of view stack as Floating View o Collapse floating view to FVB o Expand floating view from FVB o Restore to view stack from whence it came I may be mis-interpreting Eugene here so take this with a grain of salt...;-) I think that he's just saying that you sould be able configure the location of the fast view when its visible (but it still must be inside the shell). If so I'm not particularly hot on this because it allows the location of the trim bar to become completely disjoint from the location where the view gets displayed. Currently, you can resize the displayed panel and it'll reopen in that size but if you move the bar from the left to the right trim then the area then the view's display area adjusts to abut the bar (which IMO is correct behaviour). Do you have something that shoves the other views/editors out of the way (resizes) instead of overlaying them? (in reply to comment #18) Kevin, that was the intent of my original change to minimize (killing two birds with one stone...;-). Folks that want what we currently call an FVB could simply make a stack that contains the views they want, minimize it to the trim and then never restore it... As far as using something more complex than the icon I just don't think that we have the space...the current implementation already shows a ToolTip containing the View's 'name' and any attempt to keep the name visible at all times would do two things: - chew up gobs of valuable trim real-estate - fail miserably under many cases, causing endless tweaky hacks (like '...' handling etc) which would chew up resources (me...;-0) and end up resulting an implementation that was no better than not showing the name in the first place. It may be interesting to note that I haven't seen a single defect/enhancement request to provide more than the icon/tooltip for the current FVB. For my money I'd leave this as is for now and only address it if there's a strong push from the community. Ed, sorry but I don't understand... (In reply to comment #23) > As far as using something more complex than the icon I just don't think that we > have the space...the current implementation already shows a ToolTip containing > the View's 'name' I was getting ahead of myself in my comment because I started thinking about min of the editor area (where you wouldn't show 10 java editor icons) or edge cases of multiple instances of the same view. In any case I'd have to agree, I don't know what else other than tooltip we can do. I'm not big on text layed out in the trim for reasons you've mentioned. (In reply to comment #21) > I think that he's just saying that you sould be able configure the location of > the fast view when its visible (but it still must be inside the shell). Because Fast Views don't stick around long, and because they will be docked in a FVB proximal to the view stack's location ... I am not sure the compelling usage case for being able to move them. They need to live inside the shell (as you've pointed out) so the best you could do is move them along the edge. To what gain? Also note that the positioning of the view's panel isn't finished yet. It should align as closely to the location of the trim bar as possible given its size (a la context menus). Since the bars are now draggable trim they could be positioned at either the left or the right of the bottom. Currently if it's a 'vertical' view then it displays on the left side of the shell regardless of the position of the bar. Same problem with other combinations. I'll make sure that this goes into the next rev. Fast Views (in 3.2 at least) hide the whole view in the fast view bar until you click on it at which point the view is shown, obscuring some other views and/or editors that might be under it. I was just wondering if anyone had played around with a more 'expose' type of behavior where something that had been tucked into a fast view bar could be pulled out without obscuring anything (by resizing the other stuff around it). Or perhaps a 'mylar' approach where interesting panes could get bigger and uninteresting ones could get smaller, or a 'dock' approach where panes would get bigger when they have focus or you move the mouse over them. (In reply to comment #20) > I don't quite understand the suggestion, could you please elaborate? > > Quickviews have the quality that they are extremely temporary: > 1. you open it > 2. you scroll through it > 3. you select something > 4. it immediately goes away > > Detached views have a very different temporal quality (the same as regular > view, its just they get their own child shell) and thus different usage. I meant that it should be possible to resize quick views in any ways you need and do that per view. So, I can actually see what is underneath those views (and for instance use drag-n-drop). You can of course use current behavior as default, but I don't see any reason why resize need to be disabled. Another thing is to activate more then one quick view, so you can do drag-n-drop between these views. Most commonly package explorer/hierarchy view and properties or history view. Then when you click outside of these activated views they will be minimized back to the quick view bar in the same way as single quick view is doing now. > Do you simply mean the detached views should be dockable to the FVB? This is separate story, but I think that would be good idea. > For example, you could do something along the lines of the following?: > o Tear out of view stack as Floating View > o Collapse floating view to FVB > o Expand floating view from FVB > o Restore to view stack from whence it came Right. (In reply to comment #21) > Currently, you can resize the displayed panel and it'll reopen in that size but > if you move the bar from the left to the right trim then the area then the > view's display area adjusts to abut the bar (which IMO is correct behaviour). You can still leave that as default behavior, but allow advanced users to resize views to match their personal preferences. (In reply to comment #28) > Fast Views (in 3.2 at least) hide the whole view in the fast view bar until you > click on it at which point the view is shown, obscuring some other views and/or > editors that might be under it. I was just wondering if anyone had played > around with a more 'expose' type of behavior where something that had been > tucked into a fast view bar could be pulled out without obscuring anything (by > resizing the other stuff around it). Or perhaps a 'mylar' approach where > interesting panes could get bigger and uninteresting ones could get smaller, or > a 'dock' approach where panes would get bigger when they have focus or you move > the mouse over them. Ed, I filled a bug report for something like that 2.5 years ago. https://bugs.eclipse.org/bugs/show_bug.cgi?id=51011 The idea is very similar to one used by DateLens http://www.cs.umd.edu/hcil/datelens/index.shtml Committed in >20060914 (i.e. for 3.3M2). I've switched over to using a new 'experimental' 3.3 presentation to enable the new min/max functionality in order to make the features available to a wider audience for M2. You should be able to remove the '-DMultiFVB' vmarg post-M2. There are still a number of polish issues to be resolved: - Views don't maximize on all platforms due to some quirky EditorArea handling - The 'maximize' button doesn't change to a restore when maximized - There are significant animation delays on both the Mac and Linux I'm liking it...;-). The sound of a successful paradigm shift is always that of new features creeping. For now I've got my hands full just putting the polish on what we have so I doubt we'll go too much farther on the suggested enhancements such as the Mylar-style 'focus', multiple open FV's and panel resizing. I have to start ramping down on this so I can get on to my other commitments. But -please- keep the ideas and feedback coming in any case. Note that many of the fundamentals of those approaches exist in this approach; they're just not as 'cool' (and, trust me, I -like- cool). You can restore one or more of the bars while you're still maximized if you need to use DnD between views or if you don't want the view overlapping the current arrangement. A couple of minor glitches when using the latest build (20060912). Appologies if these are covered elsewhere: 1) Maximize the editor area. If you right-click on the editor tab at this point, you can see the "maximize" action is still in the menu. Selecting "maximize" will un-maximize (restore) the editor. The name of the action should change if it now has the opposite effect. 2) Maximize the editor. Restore all FVB stacks manually. Select "maximize" again on the editor, and nothing happens. I believe it thinks it is still maximized at this point and it becomes confused. Perhaps as soon as any FVB is restored the editor area should no longer be considered maximized (effectively it isn't at this point). 3) Start with a view stack containing two or more views next to the editor area. Reveal any view other than the first one (left-most) in the stack. Maximize and then immediately restore the editor area (hit Ctrl+M twice with editor active). The revealed part in the view stack has changed. Maximize+Restore should be perfect inverses - I should be back in exactly the state I started in after performing both actions. Thanks John, I'll be doing some cleanup over the weekend and I'll see what I can do with these. Activating the correct view shouldn't be too hard. Unfortunately fixing the maximize state handling will require some deeper mods; if I fire the state change events then, while the folder will show the correct state, all sorts of other undesirable side-effects happen due to other listeners doing what the think is best... Committed in >20060915. - Removed the context menu from minimized stacks. - Now saves/restores the FVB 'style' so that unzoom will know to restore minimized stacks after a re-start. Restoring minimized windows doesn't restore them in the same order. Besides this, pretty nice! This feature is nice but what I would prefer is the ability to send chosen views grouped in stacks to fast views, not all the views. For example, in the PDE perspective, the Plugins view and the Hierarchy view are views I use rarely. Nonetheless, I would like to send them to a fast view on the left of the workbench. On the right side of the workbench, I have fast views for Junit, Synchronize and CVS/SVN Repositories which I use a lot. The current implementation prevents me from chosing the views. It's far to binary with an "all or nothing" approach. (In reply to comment #38) > It's far to binary with an "all or nothing" approach. Just arrange the views in two different view stacks before you minimize them / turn them into fast views. OK, thanks, but this sounds more like a workaround than a user friendly feature. Users are currently trained (right or wrong) to send a single view to the FVB. Why would we want to have 1 bar that works different from the other FVB's a user may have created. If there are strong opinions, that there could be a preference to specify the preferred behavior. IMHO, I think the default behavior is wrong. If I'm debugging I may want to shuttle off to the side my breakpoints view, but I definitely wouldn't want to take the variables view along with it. Still, if I really want to have this arrangement, I have to drag one or more views below, beside, above the other views, for the sole purpose of getting the tool to send my specified views to the FVB. This is hokey because the user already selected their views when they had to drag them into a "fake" grouping. Binyan, we intentionally moved away from the full-on FVB paradigm (dragging etc). There's no guarantee that users picking up the new min/max behaviour are FVB users so exposing them to the FVB's full capabilities would likely either confuse or scare them with its complexity. Personally, I think that having to do the stack arrangements using the 'normal' mechanisms and then minimizing the result is actually a win. It's better to have two orthogonal -simple- operations (arrange stacks / minimize) than one complex one. Eric, I wonder where these conclusions came from? Have you done any user study on this? (In reply to comment #41) > Binyan, we intentionally moved away from the full-on FVB paradigm (dragging > etc). There's no guarantee that users picking up the new min/max behaviour are > FVB users so exposing them to the FVB's full capabilities would likely either > confuse or scare them with its complexity. > I'm by no means trying to say I know the "one true way", however I am saying don't block me from exercising a behavior that I've grown accustomed to. Perhaps we are debating a semantic difference. You talk of new min/max behavior, but what I see is views that get moved to a _new_ FVB on the right, left or bottom. If it looks like a duck, quacks like a duck, but is called a platypus then we're going to breed confusion. For old eclipse fogies like me, this is _just_ the ability to have more than 1 FVB, which is something we have wanted for many moons btw. So if this had of been positioned as we just added the ability to have multiple FVBs and as a bonus you can now minimize and maximize a FVB as a group, then the behavior would be *consistent* and I don't think we would be debating this. Also if the user is new to eclipse I find it hard to believe that they would NOT be confused by the current behavior which functions exactly like the normal FVB with the exception of min/max behavior. That 10% difference is not worth the extra hoops that have to be jumped through. BTW, your last sentence on exposing them to the FVB's full capabilities would likely either confuse or scare them with its complexity is interesting to say the least. Are you proposing to take out the current FVB behavior to shield these new users from being scared/confused by the current FVB behavior? I'm 99.999% sure you're not. Thus it is the intention to move forward with 2 ways that are extremely similar in an effort to reduce confusion. OMG you killed Kenny, twice!! > Personally, I think that having to do the stack arrangements using the 'normal' > mechanisms and then minimizing the result is actually a win. It's better to > have two orthogonal -simple- operations (arrange stacks / minimize) than one > complex one. > That's your opinion and I support that. I don't agree with it, but I do support your right to have it. Nonetheless, I think this issue embodies sub features that are being lumped into one issue. Try the following questions and see how they grab you. 1. Would users benefit from having more than 1 FVB? I believe this is a yes. 2. Would users want to arrange the views in the new FVBs? Yes again IMHO. 3. Would users want to arrange the position (right, left, bottom) of the new FVBs? Yes again IMHO. 4. Would users want to minimize/maximize a FVB as a group? I say yes again because it is an additional feature applied to all FVBs, not just some. (In reply to comment #43) > 1. Would users benefit from having more than 1 FVB? I believe this is a yes. > 2. Would users want to arrange the views in the new FVBs? Yes again IMHO. > 3. Would users want to arrange the position (right, left, bottom) of the new > FVBs? Yes again IMHO. > 4. Would users want to minimize/maximize a FVB as a group? I say yes again > because it is an additional feature applied to all FVBs, not just some. Binyan, aside from the 'technique' used to manage the arrangement issues mentioned in 2) I think that the current implementation covers the rest. Do you agree? BTW, as you can see from comment #3 I started with something much more akin to FVB's. I was subsequently convinced that the simpler style is superior (I mean really, truly convinced, otherwise I'd have said 'convinced'...;-). This came from feedback from our internal guinea pigs who were beat into using it in its earliest incantations. (In reply to comment #43) I wanted to provide some context to the design direction that Eric is on (begin soapbox): As the audience for Eclipse widens, a growing (and legitimate) complaint is that it is too complex. There is much in Eclipse that supports the power user, but by doing so, creates an overly configurable environment for the new user. The more options something has, the less usable it is (but can more powerful). Its great you get to use Eclipse in exactly the way you want, but if you are new to it, you don't know what that is, and all this configurability just confuses you. Would users want to have multiple FVBs, arranging their content as they want, positioned wherever they want... etc... Which users? And to what end? What Eric is trying very hard to do here, which I support, is to create a sensible middle ground of a UI experience which is predictable, intuitive, and (sufficiently) powerful. The usual design approach is to make everything do everything anyone could want. The harder one is, by restricting what it can do a little, you can streamline and improve the experience for a larger audience. Usability goes up (yeah!). Power goes down a little (sorry). I will add that it is an unavoidable outcome of the community process that the power users' voices are the ones most often heard and the loudest. The voices we never hear are those who give up on Eclipse and move to something else. While its completely possible that this new work hasn't quite yet found the middle "sweet spot", I believe its on the right track. Created attachment 52703 [details]
Patch for code committed into M3
This is for safety's sake since I'll be on vacation during the M3 test-cycle.
If probelms are encountered in M3 testing -without- having the experimental 3.3 presentation turned on you can use this patch to revert the existing M2 behaviour.
Committed in >20061025. This is a complete re-write; removing the prototype code and providing an implementation that is far better integrated into the workbench. Many (but not all) of the issues are addressed by this new code including: bug 155537, bug 157872, bug 158520 & bug 158658 - Known issues are that the mazimized state doesn;t survive a shutdown/restart - Ctrl-M handling no longer works to 'unzoom'. - Views (i.e. ContentOutline) that are in the layout in one perspective and in the trim in another don't 'hide' on the perspective switch. You can simply open/close the fastview to clean it up. Committed in >20061026. Restored the FastView behaviour back to it's 3.2 implementation since it's no longer used in the min/max story. Adding McQ... This is just anupdate to assure folks that this feature is -not- languishing due to lack of interest. Far from it, we're finalizing how to handle the current defects which appear to be in two basic areas: ViewStack / TrimStack not maintained as equivalent and not maintaining the correct min/max/restore state throughout the hierarchy. My M4 cycles were dedicated to doing what I can to help Paul come up with a new Commands story. Since this is primsrily an API feature it had to happen soon enough to ensure that it'll be done by the end of M5 (API Freeze, apprpriate considering when M5 finishes and where I live...;-). Q1. Will I be able to drag an open Eclipse view directly to a FVB? Q2. Will I be able to drag the icon for a view from one FVB to another FVB directly (without first having to restore both FVBs, then drag the view from one view stack to another, then minimize both stacks)? Many thanks, Julian (In reply to comment #51) Julian, yes, in the updated version you will be able to drag views into/out of and within a TrimStack ("FVB" I'd like to reserve for the legacy FVB). TrimStacks maintain a one-to-one relationship between a ViewStack in the presentation and a ViewStackTrimPart that can represent it in the trim. The result will be the same as the corresponding operation had the stacks been in the presentation rather than in minimized stacks; dragging within a TrimStack will change the order of the tabs when the stack is restored to the presentation and dragging between TrimStacks will update the presentation to ensure that the view is moved to the target stack (in the appropriate slot). Also we anticipate adding a 'Close' context menu item to views in FVBs but mot providing the complete set of operations available from the existing 'global' FVB. Couple comments based on user experience w/ Linux (Debian/ubuntu), using Eclipse 3.3M4. a) animation of small black rectangles moving to left/right/bottom edges is rather slow. Could be my machine. Turning off animations from Window > Preferences... > General > Appearance makes the experience better. b) CTRL-M keybinding (maximize/restore) now only works for maximize. Second press of key no longer toggles max/restore. c) ability to maximize stops working if you perform the following steps: . start eclipse . open any file (in editor space) . maximize editor (double-click editor tab) . close editor (screen is blank, as no editor is open and all other views are minimized) . open navigator/package explorer . open new file . double-click editor tab: max/minimize not working (nothing in Error Log view, by the way) . shutdown/restart eclipse. min/max function works again Other than these issues, this is a great new way to organize a perspective. Kudos! I've been using the experimental 3.3 Presentation in Eclipse 3.3 M5 and it seems to break when a fast view is created and then moved into a tab group that is then minimized. The tab group either fails to minimize or disappears entirely and is no longer accessible even through Window>Show View. This seems to happen only with the left hand views. Committed in >20070228. Oh boy, now I've done it...no, I mean I've done it!! This is the third (and final!) pass at the new min/max behavior; including Dnd and closing of trim views etc. Intro is still not showing correctly due to its use of an 'internal' listener that's listening on the old min/max rather than on the IntroView's state (as it should be). I'll be marking many of the dependent defects as FIXED as I go through the scenarios. The biggest change is that this version is waaaay less likely to completely hose the Workbench Window's state... Are you going to send UA a patch for the Intro problem? I'll see if I can make it work with the current logic. If I can't I'll make a patch... Woo Hoo! I get to declare this as a done deal!! Not completely of course but the work item part is done and the remaining issues are 'edge polish'... sorry to be coming into this late, but... what happened to the minimize button that was available to me if i 'stacked' editor views horizontally or vertically (ie: i could be editting in one window will looking directly at source in another window)? w/ this new feature, i only see one min/max button, which controls the whole editor area, as opposed to previous versions where each editor 'group' got it's own min/max button to control all open editor windows contained w/in that group. will the ability to minimize editor groups come back, or does this already exist and i'm missing something. if any of this is confusing, pls let me know - i'll post a screen shot. Created attachment 72416 [details]
screen shot
the screen shot illustrates what i was trying to ask - the top group of editors has the minimize button, but the bottom group does not.
(In reply to comment #59) > sorry to be coming into this late, but... > > what happened to the minimize button that was available to me if i 'stacked' > editor views horizontally or vertically (ie: i could be editting in one window > will looking directly at source in another window)? > > w/ this new feature, i only see one min/max button, which controls the whole > editor area, as opposed to previous versions where each editor 'group' got it's > own min/max button to control all open editor windows contained w/in that > group. > > will the ability to minimize editor groups come back, or does this already > exist and i'm missing something. > > if any of this is confusing, pls let me know - i'll post a screen shot. Hi Jae, The short answer is that its no longer supported. Split editor areas were always an anomaly, not fitting in to the same metaphor as the view stacks. Each view stack is discrete and can be minimized on its own, while as the split editor area behaved more like stacks within a stack, or something. Also it relied on the editor area collapsing in-place which we no longer support (now they go to the trim). One goal of the min/max/trim work was to rationalize the metaphors around our stack treatment, which I think we did a pretty good job at, but the split editor area wouldn't fit. We're sorry if this was a behaviour you used often. You can of course still manually move the split sash to expose more of one editor mini-stack. We discussed two alternatives but were unable to implement either in 3.3: 1) Support multiple editor areas as real stacks onto themselves (just like you can have multiple view stacks). This is a huge change but seems the right one. 2) Have a split sash between the editor areas that you can easily flip to one end or the other, to either be midpoint, show all of one side, or show all of the other. This would duplicate closer the old split editor behaviour while not introducing an special/odd behaviour for stacks of editors. |