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.

Bug 20153

Summary: There is no support to programatically customize Dock View Into action.
Product: platform Reporter: Jan Jancura <jjancura>
Component: ActionsAssignee: David Simonek <dsimonek>
Severity: blocker CC: tor
Priority: P1    
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on: 26660    
Bug Blocks: 20152    

Description Jan Jancura 2002-02-05 12:31:37 UTC
We can redefine org.openide.actions.UndockAction.
May be I missed somethink, but I can not find similair action for Dock View Into
Comment 1 David Simonek 2002-02-07 15:33:33 UTC
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
Comment 2 Jaroslav Tulach 2002-03-12 10:19:44 UTC
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...
Comment 3 David Simonek 2002-03-12 10:45:56 UTC
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. 
Comment 4 Jan Jancura 2002-03-12 12:35:14 UTC
No it is not. It is not consistent with the rest of our IDE. We should
find some way how to do it. 
Comment 5 Jaroslav Tulach 2002-03-12 13:57:22 UTC
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.
Comment 6 David Simonek 2002-03-12 14:57:15 UTC
raising to P1 to reflect that this is krakatoa defining.
Comment 7 _ hair 2002-03-13 02:51:57 UTC
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 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[] ) 
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.
Comment 8 David Simonek 2002-04-17 16:35:00 UTC
accepting issue...
Comment 9 David Simonek 2002-04-18 09:31:04 UTC
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
Comment 10 David Simonek 2002-04-23 13:25:36 UTC
implemented in main trunk:
- added method List availableModes(List modes);
- tests are located in core/tests/unit/windows/

Hanzi, please look at tests so you know how approximately should look
your special mode implementation.