Community
Participate
Working Groups
Here are the steps that I need to follow to open a new property view and have it displayed in the bottom of my perspective: #1) Click on the Perspective menu #2) Click on the Show View submenu #3) Click on the 'Other...' option #4) Find and select the Properties View (The Properties View now appears as a Fast View) #5) Click on the restore button (The Properties View moves to the right side of the window) #6) Drag the view to the bottom, where I want it This seems like too many steps, and it involves chasing the property view all over the window until I get it where I want it. I find it a very unnatural, frustrating UI experience, because I have little control over where the view is going to appear next. I would like a menu item on a view's title bar context menu to open a new view in the same tab group. This PR is related to Bugzilla Bug 2311 "Should be able to drag back fast views (1GENSQ5)", as it would partially eliminate step #5, which is probably the most counter-intuitive step in the sequence. I suspect that there are accessibility issues here, too, as doing this task without the aid of a mouse would be extremely difficult.
It would be worse if the UI aribrarily chose where to put the new view and messed up the layout that you had made. When the perspective does not have a place holder for the view it will apear as a fast view. There are no plans to change this behavior in 2.0 Adding support to drag the fast view back, instead of restore, relayout is a reasonable enhancement.
I agree that the UI needs to guess something. However there is a simple way to provide a hint to the UI. Add a context menu item to an existing view's title bar context menu to open a new view in the same tab group. The context menu already has tab group actions (Move->Tab group), so I think that it's an appropriate place for this. It doesn't solve the whole problem, but it provides a quick solution to one of the most common cases.
We should add support for drag/drop fastviews. There is an oustanding defect report for the ability to declare placeholders for views that are not visible. This will mean that it would be possible to declare a preferred location of a view so it goes in a "nice" place within the perspective. Check with Simon about the status of this, I believe this enhancement was going to be contributed by an external developer. We are not planning to revert to the 1.0 behavior where views programatically chose where to destroy the perspective layout for 1.0. The context menu idea is interesting, we will consider this post 2.0
Ryan is looking into fast view dragging. I don't think making everything appear as a fast view is too tasty though. We should also allow a view to specify where it would like to appear. A simple mechanism would simply indicate which side it wants to be docked to, and its preferred dimensions. If it was the first view to appear on that side, it would use its dimensions. If not, it would be grouped in a folder with the other views on that side and the dimensions would be ignored. Of course, different people (and different perspectives) may have different preferences for where things go. Perhaps these prefs could be specified on a per-perspective basis. Whatever we do, the same flexibility should be available whether the view is being added to the perspective in code or declaratively in XML.
There has been some discussion (check with Simon for details) on supporting declarative creation of placeholders for a perspective. This would give you much of what you are looking for - per perpsective optimized layout of views.
Build: 20020508 Right now by default, a new view without a placeholder is squeezed in between the rightmost part and the edge of the window. This is annoying, especially if the user opens up several new views. In that case, the layout gets very cluttered and the user is practically forced to rearrange it. I prefered when new views whose place wasn't specified appeared as fast views. Now that fast view dragging has been implemented, fast views aren't as much of an inconveinence, and they definitely make the layout less cluttered than dumping new views on the right side of the layout. Just my 2 cents.
Others decided that opening as a fast view was confusing for new users. I agree, now that you can d&d them, this may not be such a big problem. Also, now that the extension point to customize a perspective can handle view placeholders, that will help too. My personnal view is there is not enough "visible cue" that the view is open as a fast view. If it was more obvious, we could stick with opening as fast view. Probably no time to address this issue for release 2.0
We should consider other possible improvements for initial non-fast view placement. Adding it to an existing folder may be preferable than giving it its own area. Views should be able to specify their preferred position independent of perspective.
Defer
Reopen to investigate
- There is another problem report about initial position of views. - Now it is possible to drag fast views. The pendent issue here is the idea of adding a menu to open view in the view's menu which I don't know if it will ever happen.
It appears that these issues have been resolved.
