One more question on DnD support.

[Kit Strong]

Let's say I have my own custom View in Oxygen which contains a JTree which has .setDragEnabled. Is there a particular DataFlavor or TransferHandler I need to use in order to leverage the existing DnD support in Author mode?

[Kit Strong]

I can't seem to edit or delete my original thread so here's a bit more specifics on what I'm trying to do.

In my Custom View I have JTree where the Leaf Nodes contain, among other data, a Java File object pointing to the resource in question. So the main question is how do I convert that File instance into a Transferable that the Author Mode can handle for Dropping topic references and such?

Thanks,
Kit

[Radu]

Hi Kit,

The resource drop targets installed in Text, Author and DITA Maps Manager view already look for about 2-3 flavors in the transferable.

Basically when you drop something, our existing code which listens for resource drops receives a "java.awt.datatransfer.Transferable" object in which it looks to see if different flavors are supported.
One flavor it looks for is "java.awt.datatransfer.DataFlavor.javaFileListFlavor":

Code: Select all

      if (tr.isDataFlavorSupported(DataFlavor.javaFileListFlavor)) {

        // Is a file list.

        List<File> fileList = (List) tr.getTransferData(java.awt.datatransfer.DataFlavor.javaFileListFlavor);

.......................

So it can obtain dropped Java IO File flavors and insert links to the resources accordingly.

It also looks for a more generic flavor:

Code: Select all

DataFlavor FLAVOR_LINUX_LIST_OF_URIs = new DataFlavor("text/uri-list;class=java.lang.String", null);

and when it is supported, our code tries to obtain a java.lang.String object from the transferable which it then splits by line breaks \n and treats each fragment as an absolute URL-like path to a resource.

Regards,
Radu

[Kit Strong]

Cool, I had kind of guessed it was using the javaFileList flavor at a minimum but I wasn't entirely sure/

One thing I have noticed, which has made me step back and consider other approaches, is that the behavior when dragging files into the Author view is very inconsistent. Sometimes it does what I want and creates a <topicref> but just as often it simply opens the file in another tab. It seems much more reliable when dragging files.

-Kit

[Radu]

Hi Kit,

Let me try to explain the current behavior:

When dropping resources from the Oxygen Project view everything is consistent, you will always get links to the dropped resources. The same goes when dropping resources from the DITA Maps Manager in the Author visual editor (Oxygen 16.0).

But when dropping stuff from outside (Linux or Windows external File Browser for example) the problem is that we do not know the user's intentions, if he wishes to open the resource in Oxygen or to link to it. So we consider that when binary files are dropped (like images) the user wants to link to them but when resources or XML types which are known by Oxygen are dropped we consider that users might want to open them so these resources are opened instead of being linked to. For example I tend to drop resources from the windows explorer into Oxygen quite a lot in order to open them instead of using the File->Open to locate again the resources.

Linking to resources is also done when copy/pasting them. So for example you can copy a resource in the external File Browser and then paste it in the Author view and a link will always be made to it. So copy/paste works consistently 100% of the time to create links to resources.

Regards,
Radu

[Kit Strong]

What about in DitaMap Manager?
I am trying to drop in a Transferable which supports the javaFileList DataFlavor and I get the '+' icon indicating it;s a valid drop target but nothing actually happens.

-Kit

[Kit Strong]

Here's the bit of code where I'm setting up the Trnasfer Data:

Code: Select all

	@Override

	public Object getTransferData(DataFlavor flavor)

			throws UnsupportedFlavorException, IOException {

		[b]System.out.println("GET TRANSFER: " + flavor);[/b]

		if (flavor.equals(DataFlavors.resourceFileFlavor)) {

			return resourceFile;

		} else if (flavor.equals(DataFlavor.javaFileListFlavor)) {

			List<File> list = new ArrayList<File>();

			list.add(resourceFile);

			[b]System.out.println("TRYING TO DROP "+ resourceFile.getName());[/b]

			return list;

		} else{	

		System.out.println("UNSUPPORTED FLAVOR");

			throw new UnsupportedFlavorException(flavor);

		}



	}

I'm getting the following Output so it's definitely using the javaFileList and retiring a Java File object (in a List of course):

GET TRANSFER: java.awt.datatransfer.DataFlavor[mimetype=application/x-java-file-list;representationclass=java.util.List]
TRYING TO DROP MyTestCMSTopic.xml

[Kit Strong]

UGH, Just ignore my previous 2 posts. I failed to notice that the Map I was testing with wasn't checked out and therefore was Read only. And since I've set the global option to dial low edits of Read only files...

[Radu]

Hi Kit,

I understand. Did you use the API ro.sync.exml.workspace.api.editor.page.ditamap.WSDITAMapEditorPage.setEditable(boolean) to set it read-only? We'll try in a future version to automatically disable actions and drag and drop acceptance when the map (or a file opened in the main editor) is marked via the API as read-only.

Regards,
Radu

[Kit Strong]

Hi Kit,

I understand. Did you use the API ro.sync.exml.workspace.api.editor.page.ditamap.WSDITAMapEditorPage.setEditable(boolean) to set it read-only? We'll try in a future version to automatically disable actions and drag and drop acceptance when the map (or a file opened in the main editor) is marked via the API as read-only.

Regards,
Radu

Yes, that's exactly what I do and it's actually exactly what I want. Our CMS is single user checkout only so our default behavior is that nothing can be edited if the resource isn't checked out and that's the way we want it. What would be more useful is to get notifications when the user does try to write to something that's read only and setEditable is set to false.

In our case having the map being updated when it's read only would be a bad thing because there are many things the user can do which will cause an update from repository and overwrite those changes.

[Radu]

Hi,

Just to update this thread, in Oxygen 17 once you disable editing most of the relevant actions will be automatically disabled + drag and drop will also react accordingly.

Regards,
Radu