This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Undocking Windows in MDI | ||
---|---|---|---|
Product: | platform | Reporter: | gu6526 <gu6526> |
Component: | Window System | Assignee: | David Simonek <dsimonek> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | alexlamsl, normanfo, paulby, wadechandler |
Priority: | P3 | Keywords: | UI |
Version: | 5.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 70863, 50352, 70861 |
Description
gu6526
2004-04-19 08:17:18 UTC
Other applications do this as well. I wrote about this in the Netcat 5.0 program. The application will be in MDI mode and a tab or TopComponent can be dragged out into a separate window to stand on it's on (in it's own JFrame). Now the window can be maximized and what ever regardless of the main MDI window. It would also be handy if this window could be set from a GUI control on each window (not API as obviously JFrame now supports this) to stay on top. Is it possible we can get this for 5.1? I would love to have this for some RCP applications. well, everything is possible :-) We just need to know exact use cases why and what this will be good for, which other apps do that (to learn from their approach and do not repeat their mistakes) and so on. For example I personally never felt the need to drag editor window out of the MDI space, so I'm curious why we got so many requests for this and where I could learn more... One use case: Create a dockable/undockable tool window: Tool windows in Photoshop are dockable or can be undocked and moved around (it lets the user layout the tool to where ever is easier for them to get to with the mouse. Sometimes having it over the picture itself is easier so mouse movent is like a few pixels to switch options on a tool while you're working). OpenOffice.org does this as well yet it's a little different in cases (maybe all) (i.e. Styles and Formatting or F11). The window is top level and can leave the work space, and then is minimized with the main window. I'll try to think of more. TC = TopComponent It would be good for this to be something you could turn off on a TC by TC basis. So, for instance, an RCP application could allow certain TCs to be undockable and then set some of them to not be. That way it's more controllable. It would be nice to be able to full screen this undocked window as well. Sort of like what happens with Firefox or Internet Explorer when you full screen a window. Though it would be nice to also full screen an entire platform based application in this way including the IDE. I searched the issues related to full screen and don't see anything I think I'll file a separate issue all together. I can't think of why TC has the choice not to be "undock" - I mean, what disaster would it become of if user undocks an undockable TC? ;-) In some cases one wouldn't want to allow a window or TC to be moved around. So an option to disable a given TC from being undocked would come in real handy. Some users just simply can't get some things, and other cases you want screen shots in documentation to match a static layout. So, having some areas undockable means the documentation always matches the layout and the users can't get terribly confused. One use case where disabling the undocking of a TC would be certain head start applications. I used to work for a company who wrote head start (early child hood school) applications, and the teachers in that arena simply did not understand what we would consider simple concepts. When they didn't understand something (even when simple) they would flood the help line with something which seemed so simple to even novice computer users. Anyways, that's a simple example. Other examples would be if you had two TC's where each was on a tab (so two tabs) inside of a tab. Sort of like the Form editor and source editor window where you switch between the designer and the code. You wouldn't want the form to be moved some where and hidden from the user and the code still in the other tab of the tab. So, in that case disabling undocking of those inner tabs make sense. The top tab would be a good candidate for being allowed to be undocked however so the form and the code could be edited in a full window. I currently have an application I would like to be able to do that with now. Full screen editor if the user chooses to undock it along with the grapical editor. So, the more flexible the undocking the better in my opinion. This feature is called Floating Frames in visual studio. IMHO it's a very useful feature and I'd love to see it support in NB. This feature would provides many of the benefits of SDI mode but without lots of the issues that SDI also had. We have a need for the floating windows feature for a framework for a project my group is presently working. I would like to vote to include this feature. Yes, this issue is included now in our workplan and I can confirm we'll try to implement it into next release. Should behave similar to Visual Studio AFAIK. Our development team is planning to make use of the NetBeans Platform for a re-engineering our satellite imaging application BEAM (see http://www.brockmann-consult.de/beam/). It would be very desireable for our users (more than 1000) to keep our floating "tool windows" (see screenshots on BEAM home page) and at the same time exploit the nice TopComponent/Mode capabilities such as node selection, docking and tabbing. Implemented in main trunk, views and editors now can be dragged and dropped outside of main window on second monitor. Can these be programatically undocked easily through an API or does one have to mimic drag and drop by trying to walk the component hierarchy (seems like that would end up a pain). Hello wadechandler, no there is no programmatic API for undocking, we have no use cases, you seem to be only one so far that needs that. However, you can define mode in xml layer as separate and then it will be opened separate when platform is started. I'd also like to have the ability to undock windows through an API. I think a good use case would be a toolbox window such as those found in Open Office or GIMP. Say I open a new file and want to have a toolbox modifiable for each opened file such as GIMP. If it is not programatically settable, then how would one do that now for each opened file? Would mode actually work for that? I don't think so, but may be wrong. Also, OO when I hit F11 opens the style toolbox window. It is not docked by default, and in fact I have never docked it. I suppose with that a mode could be used in the layer, but that seems like something that would be available without the mode having to be specific to me. I'd also like to have the ability to undock windows through an API. |