Bugzilla – Full Text Bug Listing
| Summary: | [DetachedViews] Detached view behavior and accessibility | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Randy Hudson <hudsonr> | ||||
| Component: | UI | Assignee: | Stefan Xenos <sxenos> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | aallowat, douglas.pollock, erich_gamma, jeem, markus.kell.r, n.a.edgar, sgunturi | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | 3.1 RC2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Randy Hudson
Detached views need to minimally be accessible from the keyboard. If the workbench window is maximized, there is no way to float a view. A "float/detach view" action would benefit all users. Automatic docking of the floating view to the workbench should not be the default behavior, it could be available when someone presses ctrl+drag or some explicit key combination like that. Also floating views should be movable, resizeable, etc. with the keyboard alone. There definitely should be a way to float a view in front of the main workbench window. However, detached windows are intended specificially to help make use of screen real-estate outside the main Eclipse window, so a single monitor system containing a maximized Eclipse window is not the primary use case. We already have fast views and all sorts of docking features to make use of screen space within the workbench window. Keyboard accessibility for detached windows is a separate (and much higher priority) issue. I have filed bug 63453 for the keyboard accessibility issues. > detached windows are intended specificially to help make use of
> screen real-estate outside the main Eclipse window, so a single monitor system
containing a maximized Eclipse window is not the primary use case
I'd have to completely disagree. A single monitor system *is* the primary use
case because no one uses dual monitor systems.
Floating views provide a way of overlapping a view on top of the workbench
window in a way which binary partitioning is not flexible enough to support. It
is much less intrusive than the current docked view mechanism, which resizes
existing panes just to open a view. For example, the user wants search results
to popup without stealing space from the editorpane.
Actually, there have been two ways to drag a floating view for a while. You can pickup the Tab, in which case you get agressive docking. Or, you can click on the dead tabfolder space between the tab(s) and toolbar, in which case docking is disabled. But, this is not easy to find and the difference is not obvious. Also, you can't quickly dock a stack of floating views :-) who cares. The remaining parts of the bug, especially the ability to float when workbenchwindow is maximized, are addressed by accessibility. So a mouse user should be able to select "Float View" from the view popup menu. OK, comment 6 no longer applies in M9. So the behavior is getting worse not better. In addition, I noticed that the floating view itself gets in the way of targeting the workbenchwindow behind it. Docking is too agressive, buggy, and not accessible. Please add a simple "Reattach" menuitem, and make it so that dragging a detached view does not reattach. BTW, keybindings are not working in detached views. For example, Press CTRL+H from a detached search view. It should bring up the search dialog. +1 for less aggressive docking. The "view menu > Detached" toggle should be the only way to reattach a floating view to its parent workbench window. FYI, detached windows once worked as suggested in comment 0 (briefly in 3.0), but we removed the extra context menu because we recieved a lot of comments from people who found it confusing. We've been considering fixing by enabling the OS trim around the detached window. When you drag using the OS title bar, it always floats. When you drag from the tab or content description area, it always docks. This requires changing the appearance of detached views so you don't see a double title when there is only one view in the stack. > we recieved a lot of comments from
> people who found it confusing.
You've also received a lot of comments about how annoying the agressive docking
is. What does Visual Studio do?
Created attachment 21666 [details]
demo patch for workbench (has bugs)
This patch demonstrates a possible fix:
- Re-enables the OS trim
- Changes the appearance of detached views to omit the dual title
- Dragging from the OS titlebar never docks. Dragging from the tab area or
toolbar always docks.
- Improves the appearance of detached views on all non-windows platforms.
- Enables minimize and maximize for detached views.
- Fixes stacking of detached views.
This was under consideration as a 3.1 polish item, but it has not yet been
approved. The main criticism is that the OS toolbar takes up too much extra
screen real-estate. Several alternatives were suggested in my discussion
Jean-Michael and Michael Valenta. Here are all the known suggestions for the
stacking problem:
1. Add a new "drag without docking" handle to the top-right of the view.
2. Add a new "drag window" option to the system menu that does not stack.
3. Live with the wasted pixels on windows, and enable the OS trim on all
platform (as this patch does).
4. Add various detached window modes (as originally suggested by this PR).
5. Add a modifier key for drag-without-stacking, along with a status line
message during normal drags to help users discover the modifier (as suggested
in another PR -- not currently possible without new SWT API).
All of these alternatives except for #3 would require changing the appearance
of detached views on Linux to accomodate the fact that the OS trim cannot be
hidden on that OS.
This patch still has some bugs, but I'm halting work on this until post-3.1 or
it gets approved for 3.1.
Known bugs:
- With all views in one detached stack and no editors open, closing the stack
causes exception.
- Dragging a view from a decached stack to the fast view bar and back to the
stack causes an exception.
+1 to release in RC1 (from both Kevin and Nick) provided the bugs mentioned above are addressed first. Kevin also gave the +1 for the new createDetachedViewPresentation API required on the presentation factory. Approved for RC1 by Kevin and Nick. Fixed in head. Note: after chatting with Nick, we agreed that the extra space used by the OS trim is acceptable, since any other solution would require different presentation code for each OS. The solution implemented here is different from what was requested in the original PR, however I'm closing as fixed since the main use case (easy dragging over the workbench window) has been addressed. Note that the new API is not in yet -- the current fix reaches around to workbench internals. Easily addressed. *** Bug 96658 has been marked as a duplicate of this bug. *** The new API is in This patch created a couple minor DnD regressions: - The drag sensitivity for splitting a stack was reduced to 3 pixels - Dragging over the empty title area of a view stack was showing the affordance for stacking rather than the affordance for adding as the last tab (even though both have the same effect) I've just committed a fix for both issues Verified in 20050527-0900 Reopening as we propose backing out of this API for the following reasons: - see bug 97497 [DetachedViews] Rettachement option not obvious to find - in finding ways to fix this bug, it became apparent that in the end we were putting in new and different features that support dragging views and docking them which were unnecessarily different from the workbenches. The suggestion is to remove the recently added API : AbstractPresentationFactory.createDetachedViewPresentation(Composite,IStackPresentationSite ) and replace the detached view presentation with the standard workbench one for 3.1. API change approved for RC2 Actually, this is still fixed. It is still possible to drag over the main workbench window, even though most of the other changes were reverted. Verified that the requests made in the original description are met by the current design. I20050610-0010, GTK+. Part of the fix committed for 3.1 RC1 for this bug caused Bug 100737. Rather than re-open this already convoluted bug, I'll continue any analysis in Bug 100737. |