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.
| Summary: | Callback D&D support | ||
|---|---|---|---|
| Product: | platform | Reporter: | Martin Roskanin <mroskanin> |
| Component: | Text | Assignee: | apireviews <apireviews> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | pjiricka |
| Priority: | P1 | Keywords: | API_REVIEW_FAST |
| Version: | 5.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | TASK | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 53439 | ||
| Attachments: |
diff of the api change
updated diff Demo client usage of the API Updated ActiveEditorDrop with javadoc of client usage Please consider changes mentioned at previous comment |
||
|
Description
Martin Roskanin
2005-07-25 15:39:38 UTC
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 |