Created attachment 19702 [details]
Diff of way it is implemented here

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.

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).

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.

Adding also Po-Ting, since this affect editor module too.

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).

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.

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.

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.  

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.

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. 

Created attachment 23168 [details]
simplified diff of the dnd callback feature

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.

Created attachment 23170 [details]
Client demo usage of CallbackTransferable

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.

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.

Created attachment 23228 [details]
Edited diff, after simplified the changes in NB code, so it is more obvious the minimum we need

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.

I created a fast track issue #61367 for this enhancement

Since #61367 is fixed, closing this one as fixed also.