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
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
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.
? making Mode constants denoting these new types, eg Mode.NEW_SINGLE,
Mode.NEW_SPLIT, Mode.NEW_TAB, in a Mode TC.availableModes Mode )
? 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.
1) add method availableModes, possibly second method
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
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.