Community
Participate
Working Groups
Tear of views should function independently as if they were seperate applications. The problem is if I tear off a view, I want to minimize the main window, however in doing so it also ends up minimizing all the torn off views. Is there a way to keep them visible? Also the editor cannot be torn off. Is there a reason why? This would be nice as well.
(In reply to comment #0) I disagree. Views are by design children of the main application window and do not have their own top-level identities in the system taskbar/dock, and minimizing the main application window should minimize the detached views as well. This is the behavior that users are used to and expect from most applications. If the user wants to minimize the entire application, he/she shouldn't have to minimize the main window -and- all the torn off views separately. It sounds like what you really want is a way to pop your view into a full-fledged top-level shell. It's not something that can be as easily done as clicking "Detached" in the view context menu, but I don't think your suggestion is the proper way to go about this. It runs contrary to expected UI behavior.
I agree that my suggestion is two the extreme. It would be nice to someway provide this. I think NetBeans IDE does this. This is very useful for saving real estate or when using multiple monitors.
I've also heard requests from linux users for this behavior (linux has some more powerful window management features which make this more desireable). This is not a hard code change to make. We should investigate this in 3.2, and get some community feedback.
This has been talked about before. Look at the CVS comment for revision 1.13 of DetachedWindow. I'm very much in support of leaving the parent of DetachedWindow as null. Re comment #3: This bug was filed for Windows XP.
I'm not against setting the parent to null iff this is what the majority of the community likes and it's tolerable on all platforms. I'm just against choosing a different parent for different platforms, since the parent affects the widget lifecycle. Note: if we make this change, we will either need to remove the SWT.TOOL flag or provide some obvious way to list and select detached views... otherwise there will be no way to bring them to the front on windows.
Re: comment 4 I know that this was filed against XP. That's why I pointed out that it also has been requested on Linux.
Created attachment 21800 [details] patch for workbenchwindow Here's a quick patch that implements this. I'm not sure I like it or not (and it definitely needs to be leak tested under window open/close)... but this should let any interested parties experiment with the behavior for the sake of discussion.
The line between instances of WBW's and DW's should blur to unity in the new presentation, likely meaning that what we currently call DW's need some shell enahncements (sys menu...) in order to make them work.
Eric, I find the last comment a little confusing, could you repeat it differently?
The idea is that, rather than enhance the current DetachedWindow to support a full ViewSashContainer, I'm hoping to make it a full WorkbenchWindow (whose listeners are attached to its 'main' window (so it'd be a first class shell). Note that whether we continue to tie the visibility of these windows to that of the 'main' window is a decision we haven't made yet. Binding them (i.e. making the secondary WBW's minimize/restore along with main one) keeps the desktop cleaner but it doesn't allow the discreet control asked for in the original comment.
This feature would make Eclipse a lot more usable for me, I think that having a way to "convent" or "switch" a detached window to a normal window (with minimize/maximize buttons, independent of the main window) would be the best way to implement it.
Removing outdated target milestone.
