Bugzilla – Full Text Bug Listing
| Summary: | [DetachedViews] Standalone views lose their standalone property when detached | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Boris Bokowski <bokowski> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | chris, emoffatt, harleenssahni, justin.dolezy, pwebster, rmcamara, saurav.kumar |
| Version: | 3.1.1 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
Boris Bokowski
Partial fix:
In org.eclipse.ui.internal.DetachedWindow, change the constructor to:
public DetachedWindow(WorkbenchPage workbenchPage, LayoutPart part) {
this.page = workbenchPage;
int appearance = PresentationFactoryUtil.ROLE_VIEW;
// Be sure to change the appearance in case the view is standalone.
if (part instanceof PartPane) {
IWorkbenchPartReference ref = ((PartPane) part).getPartReference();
Perspective persp = page.getActivePerspective();
if (persp != null && ref instanceof IViewReference) {
if (persp.isStandaloneView((IViewReference)ref)) {
appearance = persp.getShowTitleView((IViewReference)ref) ?
PresentationFactoryUtil.ROLE_STANDALONE :
PresentationFactoryUtil.ROLE_STANDALONE_NOTITLE;
}
}
}
folder = new ViewStack(page, false, appearance, null);
folder.addListener(propertyListener);
}
Then in PerspectiveHelper, change all of the constructor calls to DetachedWindow to pass in the LayoutPart.
This fixes the case where you detach a standalone view, then reattach it by dragging the tab. It also fixes the case where you detach the view, close the detached window, re-open it using Window->Show View, and then reattach it.
Unfortunately, it doesn't fix all of the problems with standalone views. Remaining problems:
1. Detach a standalone view, then use the detached window context menu to toggle off the Detached menu item. This will reattach your view, but it just adds it to whatever stack is on the bottom right.
2. Detach a standalone view, then grab onto another (non-standalone) view and add it to the detached window. Presumably, if a view is standalone, it should always be alone, even in a detached window.
3. Make your standalone view be a Fast View. When you click on the Fast View icon to re-expand the view, it looks like it loses the standalone property.
I'm a novice when it comes to the workbench internals, and I got stuck trying to track down the above problems.
Sorry that I don't have a nice patch attachment with my partial fix. I am currently not set up with the latest CVS sandbox, etc. Hopefully someone can take my code and expand upon it to clear up the other issues as well.
Thanks, I'll take a look... Hmmm, so the only valid drop target for a stand-alone view would be the ViewSashContainer (i.e. a location that creates a new ViewStack) and a ViewStack that has a standalone view in it cannot be a drop target... Is there any UI indication that a view is stand-alone? Otherwise we may confuse the user with what they see as inconsistent DnD behaviour... (In reply to comment #3) > Hmmm, so the only valid drop target for a stand-alone view would be the > ViewSashContainer (i.e. a location that creates a new ViewStack) and a > ViewStack that has a standalone view in it cannot be a drop target... This sounds correct, although I'm not sure of all the gory details. > Is there any UI indication that a view is stand-alone? Otherwise we may confuse > the user with what they see as inconsistent DnD behaviour... Good point. There is no UI indication. I wonder if this was something that wasn't completely thought out when standalone views were implemented? For example, in my app, I have a "Command Line" view that is only a single-line text widget. In this case, it is fairly simple for the user to understand that they aren't allowed to stack this Command Line view with other views. We thought about using a standalone view without a title, which makes it very obvious that this view is "different" from the other views, but unfortunately, then you can no longer drag the view to a different location within the window... Maybe there should be a feature/enhancement request to make the view tab look different for standalone views? Regardless, it seems like this bug is still valid: if we allow standalone views at all, then we need to restrict where they can be dropped. Moving to M7. Simply out of cycles...deferring to 3.4. *** Bug 172151 has been marked as a duplicate of this bug. *** No chance this could get done in 3.4.2 then?! 8) Would love this to be fixed, so I can use regular detached views for a certain thing in my product instead of my current hacked-up approach. Unfortunately no...3.4.2 is already into Release Candidates... Moving to triaged state. Chris, if you want to contribute a patch I'd be happy to review it but I'm swamped so this would likely be the only way that a fix might make it into 3.5. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |