Bug 96323 - Need ability to dock and undock TopComponents programmatically to/from a Frame or Dialog
Need ability to dock and undock TopComponents programmatically to/from a Fram...
Status: NEW
Product: platform
Classification: Unclassified
Component: Window System
6.x
All All
: P1 (vote)
: TBD
Assigned To: issues@platform
issues@platform
:
Depends on: 96321
Blocks: 179047
  Show dependency treegraph
 
Reported: 2007-02-22 15:59 UTC by _ wadechandler
Modified: 2013-05-23 21:07 UTC (History)
4 users (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 _ wadechandler 2007-02-22 15:59:48 UTC
We need the ability to dock/undock TopComponents programmatically to/from a
Frame or Dialog.  The reason is toolbox/tool windows are very common in many
softwares.  Making this easier to do for developers and being able to show how
easy it is will make it easier for them to transition more applications on top
of the Platform.  It is 1) a usability issue and 2) an application support
issue.  Currently I'm not even sure how one could allow the user to undock their
TopComponent into a JDialog if it is even possible, but this needs to be
possible.  It also needs to be possible by a method call.  Some times this needs
to be done by the call of a button.  The user needs to be able to press a button
and a tool/toolbox window move to a location near the cursor.  This is very
handy in graphics applications.  Other applications this may be handy.  It
should be a couple method calls if issue #96321 is implemented.  I set this up
as a P1 as it will be a good benefit when Netbeans 6.0 comes out to be able to
support this feature for developers.
Comment 1 _ wadechandler 2007-02-22 16:50:06 UTC
Methods would be:
Dialog undockToDialog()
Frame undockToFrame()

Window undock()//uses the default undocking method setup for the TopComponent
and by using Window it can represent a Frame or a Dialog and by using Frame and
Dialog instead of JFrame and JDialog it is consistent with the WindowManager
(they are really JFrames and JDialogs but these extend Frame and Dialog
respectfully)

The above methods return the Window, Dialog, or Frame reference so the developer
can control screen placement.

dock()//docks it to the mode it came from or its default

The point is to just make it easier to program for the end developer.  Use cases
are just that...to better support the end developer with this functionality. 
For instance, what if in a graphics application when a certain tool is selected
or when the cursor is held down on the tool button long enough the toolbox
window automatically comes out to the user to be near their cursor.    It sounds
like something which could come in handy for me with some graphics tools I
use....when I have to migrate all the way across the screen to select another
tool related to what I'm doing.
Comment 2 longstrb 2008-03-26 18:50:27 UTC
I really need this behavior ASAP!
Comment 3 Lukas Hasik 2008-03-27 15:12:20 UTC
longstrb, go ahead and provide the API and implementation by yourself... (isn't it open source product?)
Comment 4 longstrb 2008-03-27 17:23:43 UTC
It sure is an open source product (and a fine one).  However, I was simply reinforcing the need for this feature.

Finally,

There is a little more to it than just writing your own implementaion and API.  It requires a fair amount of knowledge 
about the Windows API and how to build Netbeans, which takes time.  I have contributed bug fixes in the past and would 
be happy to look into this if I had time.  Therefore, I will let the Netbeans core developers respond to this.  If I 
get some down time in the months to come, I will look into a solution if not already implemented.
Comment 5 err 2011-05-18 00:57:46 UTC
I've filed Bug 198657. It doesn't cover this, but there is some synergy.


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