Better handling of dragged links

[Jermolene]

At the moment, dragging a link from another browser window into the main TiddlyWiki window will import a tiddler called "Untitled" with the link URL as its text. Dragging a link into a text editor within TiddlyWiki will insert the text of the link.

It is proposed instead that:

• If the incoming link is a subpath of the directory containing the current TiddlyWiki, then the link is converted into a relative link of the form file:local/path/to/file.ext
• If dropped on a text editor then the text of the link is inserted at the drop position
• If dropped onto the main TiddlyWiki window, take different actions according to the file type inferred from the extension of the link:
  • Images (jpg, gif, png, svg, pdf): insert an image tiddler with _canonical_uri containing the incoming link and titled with the filename portion of the link
  • Audio (mp3, ogg, mp4): insert an audio tiddler with _canonical_uri containing the incoming link and titled with the filename portion of the link
  • Text (html, txt): insert a wikitext tiddler containing the incoming link and titled with the filename portion of the link

Note that this change will not affect the behaviour of dragging files from the OS Explorer/Finder window into the TiddlyWiki window.

[felixhayashi]

Hi @Jermolene,

(the issue title sounds suitable so I will just post my problem here.)

It would be great if the dropzone widget could include the clientX,clientY in the event object that is passed to the listener. I use this widget for my taskgraph plugin and there is no way to get hold of the drop coordinates. Imo the coordinates are an important aspect of the whole operation and should be included if the goal is to make the widget universally applicable.

Here is a screenshot of how dropzone is currently used with my plugin.

You can also see it at the online demo (http://bit.ly/taskgraph).

Regards Felix

[Jermolene]

Hi @felixhayashi apologies for the delayed response.

It would be great if the dropzone widget could include the clientX,clientY in the event object that is passed to the listener.

How are you using the dropzone widget? I'd have expected something with the needs of taskgraph to implement it's own drag and drop handling.

[felixhayashi]

Hi @Jermolene,

How are you using the dropzone widget?

I am using the dropzone widget as a wrapper around the editor like this:

TiddlyMapWidget.prototype.initAndRenderGraph = function(parent) {
  if(this.editorMode) {
    // we do **not** register this child via this.children.push(dropZoneWidget);
    // as this would cause the graph to be destroyed on the next refreshWidgets
    var dropZoneWidget = this.makeChildWidget({ type: "dropzone" });
    dropZoneWidget.render(parent); 
    this.graphDomNode = dropZoneWidget.findFirstDomNode();
  }

  ...

  this.network = new vis.Network(this.graphDomNode,
                               { nodes: [], edges: [] },
                               this.graphOptions);
  ...

And it works as depicted in the sreenshot.

I'd have expected something with the needs of taskgraph to implement it's own drag and drop handling.

I try to reuse existing code as much as possible (hence the use of the dropzone widget, which works great) and the only missing piece in the puzzle are the drop coordinates that are unfortunately not contained in the json created and passed by DropZoneWidget.prototype.handleDropEvent.

-Felix

edit

Oh, by the way, I renamed taskgraph into TiddlyMap so the relation to TiddlyWiki becomes clearer. The name sounds a bit like mindmap which is nice. The name expresses that tiddlywiki's tiddlers can be linked to form a map so the wiki owner knows where to go with his/her information or how to use it.

[Jermolene]

Hi @felixhayashi

I try to reuse existing code as much as possible (hence the use of the dropzone widget, which works great)

Wow, I hadn't expected the dropzone widget to be reused like that! It's very cunning.

There may be a neater way to do it though: if your widget were wrapped in a dropzone widget (which it usually will be), then your widget could just trap the drag and drop DOM events, do your own processing, and then let the event bubble back up to the dropzone widget. The event logic sounds hairy, but it's a very DOM-friendly way of hooking into stuff.

You may want to handle the drag and drop events entirely yourself so that you can offer better feedback than the current green bar. To make that easier we could refactor DropZoneWidget.prototype.handleDropEvent() and DropZoneWidget.prototype.importData() to extract most of the processing into utility methods on the wiki object.

In any case, I'm afraid we've drifted far from the original topic of this ticket! We need to create a new ticket "Make the dropzone widget easier to use", ideally.

Oh, by the way, I renamed taskgraph into TiddlyMap

Great name, good stuff. Please send a pull request for the link in tw5.com.

[felixhayashi]

Hi @Jermolene,

Great name, good stuff.

Thanks :)

Please send a pull request for the link in tw5.com.

I just updated the resource tiddler for the plugin.

We need to create a new ticket "Make the dropzone widget easier to use", ideally.

I created a ticket: #1320

[prmadev]

other then seeing the birthplace of the great Tiddlymap, has there been any other improvements to this issue?

[Jermolene]

Hi @amirography do you mean the original problem (which is about dragging links from other browser windows, particularly those you get with file:///myfolder such as when you drag a folder to your browser), or the problem that @felixhayashi raised about adding the X,Y coordinates to the drop message?