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.