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.
We can redefine org.openide.actions.UndockAction. May be I missed somethink, but I can not find similair action for Dock View Into
Architecture team, any ideas? Move DockingAction to openide? (separate - abstract part to openide, impl remains in core). This is not very nice, however UndockAction is in openide :-( Debugger guys want to be able to work with their inner parts of debugger window as top components. (and on the other hand they need very special layout for debugger window, unsupportable by winsys in general). ?
Mode[] TopComponent.availableModes (Mode[] allModes) that by default return just the list passed in. Hanz shall rewrite the method in its component to prepend there its fake implementation of Mode with name "DebuggerWindow". The problem that we have to solve it the list of "new" modes (single frame, split, tab frame). By moving the dockInto action into core we would have to somehow tell it the list of available "new" modes. This seems simpler in the "TC.availableModes" style, because the window system implementation can automatically add list of modes at the end. Btw. I would like Michael to comment on this because I remember him having problems with heavyweight components and forbiding them to be stored in something else than single frames...
Jan, isn't it enough for you to provide special dock into action accessible via right click on your top components, calling dockInto API method? I think yes, and you'll need no support from us.
No it is not. It is not consistent with the rest of our IDE. We should find some way how to do it.
Please reread my preview suggestion. Add availableModes (...) suitable for modification of content of DockInto action and also check client property "innerComponent" that shall be set to DebuggerWindow and point to the currently selected inner component and actions Windows/DockInto and Windows/Undock shall then work on the "innerComponent" instead of whole debugger window. Hope this will work for you.
raising to P1 to reflect that this is krakatoa defining.
Adapting NetBeans to the gui of legacy native code i encountered a situation where a TopComponent must have a 1-1 relation with a Mode. The legacy code is more interested in the native window than a java TopComponent, but all the mouse and component events are from the easily subclassed TopComponent. Half my problem was solved by ModeImpl.setMaxCount(1) [preventing other TC's from entering my Mode], but i had to put a hack into ModeImpl.java to prevent my TC being docked into another Mode [and hence out of my Mode]. The proposed API above would surely solve this problem and no doubt others NetBeans application developers might encounter. Passing in the NEW Mode Types to TC.availableMode(..) is important to be able to veto (not return them) docking my TC into another NEW Mode. Suggestions ? making Mode constants denoting these new types, eg Mode.NEW_SINGLE, Mode.NEW_SPLIT, Mode.NEW_TAB, in a Mode[] TC.availableModes Mode[] ) API, or ? using Mode names and String constants for the NEW types i a String [] TC.availableMode( String[] ) API, or ? mixing both in a Object[] TC.availableModes( Object[] ) API (yuk!). If this API were to be written it would be nice if it were 'fully' functional, ie it could handle and veto the NEW mode types.
accepting issue...
Implementation notes: 1) add method availableModes, possibly second method avalableContainerTypes(String[] types)? 2) modify DockingAction to work with methods invented above 3) DockignAction must pay attention to "InnerComponent" client property and act properly 4) write testing implementation of Mode which will use availModes and InnerComponent. Hanz will ten get inspired from this test impl in his debugger.
implemented in main trunk: - added method List availableModes(List modes); - tests are located in core/tests/unit/windows/APITests.java Hanzi, please look at tests so you know how approximately should look your special mode implementation.