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 53439 - Support for DnD from & into CloneableEditor
Summary: Support for DnD from & into CloneableEditor
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 4.x
Hardware: PC All
: P2 blocker (vote)
Assignee: apireviews
URL:
Keywords: API_REVIEW_FAST
Depends on: 61367
Blocks:
  Show dependency tree
 
Reported: 2005-01-14 19:23 UTC by Peter Zavadsky
Modified: 2008-12-22 18:59 UTC (History)
8 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Diff of way it is implemented here (52.17 KB, patch)
2005-01-14 19:25 UTC, Peter Zavadsky
Details | Diff
simplified diff of the dnd callback feature (10.57 KB, text/plain)
2005-07-20 09:36 UTC, Martin Roskanin
Details
Client demo usage of CallbackTransferable (4.31 KB, text/plain)
2005-07-20 09:49 UTC, Martin Roskanin
Details
Edited diff, after simplified the changes in NB code, so it is more obvious the minimum we need (2.25 KB, patch)
2005-07-22 00:18 UTC, Peter Zavadsky
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Zavadsky 2005-01-14 19:23:48 UTC
We need a support for DnD from source editor
component and also explorer component. This issue
spans more modules, openide + editor at least.
Please have a look at the diff, which provides the
impl we are using (with extracted confidential
info). In case some help is needed please contact Tor.
Comment 1 Peter Zavadsky 2005-01-14 19:25:12 UTC
Created attachment 19702 [details]
Diff of way it is implemented here
Comment 2 Peter Zavadsky 2005-01-14 19:27:59 UTC
If the change is not acceptable, we woul'd at least need a way to
enhance/replace some features provided by editor module. E.g. if the
default implementation of NbEditorDocument is registered and retrieved
via layer, so it is replacable. Similar with editor kits.
Comment 3 Petr Nejedly 2005-01-18 16:13:49 UTC
The change is quite big, adds several public classes to openide, even
without javadoc, one of them described as hack.

I can't agree with the change as it is.
Moreover today is the feature freeze date for release4.1, while the
fasttrack api review takes a week (more time than available from the
date of filing).
Comment 4 Peter Zavadsky 2005-01-26 23:04:16 UTC
That diff which I provided isn't a suggested patch. It is just a
solution which is used here, just to get the idea what is needed
(there are supposed to be some useful comments in the sources).
Please review that stuff, you may come up with 'thinner' solution. Tor
should be able to specify more detailed info what exactly is needed.
Comment 5 Peter Zavadsky 2005-01-27 23:46:36 UTC
Adding also Po-Ting, since this affect editor module too.
Comment 6 Peter Zavadsky 2005-04-27 18:30:00 UTC
Changing summary.
Just discovered the changes made into explorer were incorect. Don't take them
into account (from the diff). Those changes will be removed.

Focus only to support of DnD from & into CloneableEditor. Maybe we need some way
to be able to add our specific TransferHandler and DropTargetListener (see the
diff in the CloneableEditor). Maybe to be be possible to supply it via some
service? (Just a loose thought).
Comment 7 Miloslav Metelka 2005-06-29 10:38:18 UTC
The basic DnD already works now in the editor.
IMHO the original change could be morphed into introducing an SPI abstract class
in openide/text containing a method that would handle the transfer. The
infrastructure would ensure that the abstract class would be callback-ed. That
could be done by setting an overriden TransferHandler into the QuietEditorPane
upon its construction with the importData() method overriden to recognize the
specific dataflavor to which the ComponentTransfer is bound and do the callback.

public abstract class ComponentTransfer {

    /**
     * Handle the transfer of the given transferable into the target component.
     */
    public abstract handleTransfer(Transferable t, Component targetComponent);

    /**
     * Create compound transferable of this component transfer and the original
     * transferable (e.g. containing the dragged nodes from the explorer).
     */
    public final Transferable createTransferable(Transferable orig) {
        // Create compound transferable of the 'orig' with added this
        // under a private flavor. IMHO ExTransferable.Single and ET.Multi
        // could be used for this.    }

}

Anyway I'm not sure whether this fits into the overall
org.openide.util.datatransfer concept so feel free to come up with a different
solution.
Comment 8 Miloslav Metelka 2005-06-29 10:40:23 UTC
I believe that in the mentioned solution the DataFlavor under which the
ComponentTransfer is stored in the Transferable does not need to be exposed public.
Comment 9 Jaroslav Tulach 2005-07-08 13:31:25 UTC
Hi guys. I do not want to be rude, but I somehow lost track of what is going    
on here. There is a diff, but then it is said it is wrong. There is a   
suggestion for new interface, but there is no comment of what it is going to   
solve. So I thought we may start from scratch.    
   
I'd like to hear what is the usecase, we need to solve, why it cannot be   
achieved now and then we can discuss the scenario how to achieve it. As far as   
I know dnd in explorer works, Mila claims there is support for dnd in editor.   
So someone please explain me, what is missing. Thanks. Meanwhile I am closing  
this issue.  
Comment 10 Martin Roskanin 2005-07-11 10:04:12 UTC
Usecase taken from nbFeature1143:

The editor needs to provide an SPI where various modules could plug in a "drop"
handler that would get invoked when a user drags&drops some object to the
editor. The handler should be able to handle the drop operation (e.g. open a
customization dialog, generate some text into the editor).

An example use-case is "code clips". The provider of code clips wants to offer
them in some kind of a clips palette. User should be able to d&d a particular
clip into the editor. A clip may be customizable (it is not just a plain text) -
a provider should be called as the clip is dropped to the editor so that it can
display a dialog for customizing a clip (e.g. in case of generating an EJB call
to allow user to select an EJB the code should invoke, etc.), after that the
provider should be able to generate code at the cursor position.
Comment 11 Jaroslav Tulach 2005-07-11 14:17:23 UTC
I see. I have to admit I do not know how to open the dialog, neither who shall 
do it. But... 
 
Please look at ExClipboard.Convertor. Imho it can be used to turn any 
Transferable into text that can be then placed into the editor. I guess that 
it would solve half of the problems.  
 
The opening of the dialog, as I said, shall not be done from 
ExClipboard.Convertor, however. 
Comment 12 Martin Roskanin 2005-07-20 09:36:54 UTC
Created attachment 23168 [details]
simplified diff of the dnd callback feature
Comment 13 Martin Roskanin 2005-07-20 09:46:19 UTC
Please consider the diff I have attached. It uses delegating transfer handler,
so it is not necessary to copy jdk's dnd functionality like scrolling etc from
BasicTextUI. CallbackTransferable is the abstract class the client needs to
implement and return as a Transfereble. Abstract method handleTransfer(Component
targetComponent) will bring targetComponent to the dropStart initiator.
CallbackTransferable may work in delegating mode, so pass your already creaetd
transferables to constructor. Feel free to change the names of classes or
package location. I will also attach a diff from client's side. It demonstrates
addition of two DraggableButtons (that uses dnd callback functionality) to
editor toolbar. Thanks for reviewing.
Comment 14 Martin Roskanin 2005-07-20 09:49:40 UTC
Created attachment 23170 [details]
Client demo usage of CallbackTransferable
Comment 15 Miloslav Metelka 2005-07-20 10:10:57 UTC
Mato, I would personally make few changes to the diff:
1) the no-parameter constructor could IMHO just do
   this(null);
2) As the CallbackTransferrable serves as an SPI I would make the non-abstract
public methods in the class to be final.
3) IMHO the FAKE_JTEXTCOMPONENT_FLAVOR in fact does not need to be public as no
clients (except the internal DelegatingTransferHandler) would need to reference it.
Comment 16 Martin Roskanin 2005-07-20 12:44:57 UTC
Yes, thanks for reviewing Mila. I will change it. But as for 3 - maybe there
will be some other drop target (not only QuietEditorPane), that will want to
implement this dnd callback behaviour.
Comment 17 Peter Zavadsky 2005-07-22 00:18:26 UTC
Created attachment 23228 [details]
Edited diff, after simplified the changes in NB code, so it is more obvious the minimum we need
Comment 18 Peter Zavadsky 2005-07-22 00:21:27 UTC
The above is a diff of simplified solution. The TransferHandler and
DropTargetListener impls were removed from NB code, which are retrieved via
lookup. And implemented outside the NB code.

This is provided just for a case it might help to achieve to fix the issue
(better describe our minimum), otherwise ignore.
Comment 19 Martin Roskanin 2005-07-25 16:35:09 UTC
I created a fast track issue #61367 for this enhancement
Comment 20 Martin Roskanin 2005-08-02 14:33:09 UTC
Since #61367 is fixed, closing this one as fixed also.