Bug 20153 - There is no support to programatically customize Dock View Into action.
There is no support to programatically customize Dock View Into action.
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Actions
3.x
All All
: P1 (vote)
: 3.x
Assigned To: David Simonek
issues@platform
:
Depends on: 26660
Blocks: 20152
  Show dependency treegraph
 
Reported: 2002-02-05 12:31 UTC by Jan Jancura
Modified: 2008-12-22 09:49 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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
general).
?
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
"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...
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 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.
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
debugger.
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/APITests.java

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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo