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.
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.
Created attachment 23273 [details] diff of the api change
I attached corrected diff from issue #53439 with Mila's comments 1 and 2 as well as Peter Z. comment, where CallbackTransferable's handleTransfer method should return boolean. Diff 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. There is an attached diff of client's side implementation in the issue #53439. It demonstrates addition of two DraggableButtons (that uses dnd callback functionality) to editor toolbar. Could you please review the suggested changes? Thanks.
I'd like to suggest small simplification in the API. Imho the CallbackTransferable should not implement Transferable as that a distracting implementation detail[1]. But then you need a better name as it is no longer transferable. I'll use ActiveEditorDrop, here, but you can choose whatever you like. However the name of the DataFlavor shall definitely change. I am not english speaker, but calling something FAKE_*_FLAVOR does not give me much trust in the API. [1] Here would be the API: package org.openide.text; interface ActiveEditorDrop { public static final DataFlavor FLAVOR; public void handleTransfer(...); } And in the javadoc of the class shall be sample usage: class MyDrop extends StringSelection implements ActiveEditorDrop { public boolean isFlavorSupported (DataFlavor f) { return super.isFlavorSupported(f) || FLAVOR == f; } // blablabla... } this imho does not change the implementation at all, keep the original spirit and clearly separates the Transferable and ActiveEditorDrop from each other as they seem really indepent.
Yes, it sounds reasonable. Thanks for the review. I did only one minor modification - method handleTransfer should return boolean. I will attach updated diff, as well as new client usage demo.
Created attachment 23334 [details] updated diff
Created attachment 23335 [details] Demo client usage of the API
Created attachment 23337 [details] Updated ActiveEditorDrop with javadoc of client usage
Fine with me, just do not forget @since, apichanges, arch document, etc.
fixed in [maintrunk] /cvs/openide/arch/arch-openide-editor.xml,v <-- arch-openide-editor.xml new revision: 1.23; previous revision: 1.22 /cvs/openide/text/apichanges.xml,v <-- apichanges.xml new revision: 1.7; previous revision: 1.6 /cvs/openide/text/manifest.mf,v <-- manifest.mf new revision: 1.7; previous revision: 1.6 /cvs/openide/text/src/org/openide/text/ActiveEditorDrop.java,v <-- ActiveEditorDrop.java initial revision: 1.1 /cvs/openide/text/src/org/openide/text/QuietEditorPane.java,v <-- QuietEditorPane.java new revision: 1.2; previous revision: 1.1
Documentation was modified. Link to undocumented QuietEditorPane was removed from documentation and apichanges. /cvs/openide/text/apichanges.xml,v <-- apichanges.xml new revision: 1.8; previous revision: 1.7 /cvs/openide/text/src/org/openide/text/ActiveEditorDrop.java,v <-- ActiveEditorDrop.java new revision: 1.2; previous revision: 1.1 I have found one minor correction to proposed and commited diff. A method canImport (of DelegatingTransferHandler in QuietEditorPane) could return true if there is a ActiveEditorDrop.FLAVOR in transferFlavors. After this client doesn't need to extend StringSelection and importData is called.
Created attachment 23435 [details] Please consider changes mentioned at previous comment
changes integrated into [maintrunk] /cvs/openide/text/apichanges.xml,v <-- apichanges.xml new revision: 1.9; previous revision: 1.8 done Checking in manifest.mf; /cvs/openide/text/manifest.mf,v <-- manifest.mf new revision: 1.8; previous revision: 1.7 done Checking in src/org/openide/text/ActiveEditorDrop.java; /cvs/openide/text/src/org/openide/text/ActiveEditorDrop.java,v <-- ActiveEditorDrop.java new revision: 1.3; previous revision: 1.2 done Checking in src/org/openide/text/QuietEditorPane.java; /cvs/openide/text/src/org/openide/text/QuietEditorPane.java,v <-- QuietEditorPane.java new revision: 1.3; previous revision: 1.2 done