Drag-and-Drop Photos

[polyglot-jones]

I'm hoping I'll find that it's possible for a ST extension to detect a drop. If so, my idea is to see if the item being dropped is a photo and then compose an appropriate image:[] macro call. Furthermore, if there is an :imagesdir: attribute defined and the photo is being dragged in from outside of that directory, then it would copy the photo there first and then point to the copy instead of the original.
The tricky part will be if the :imagesdir: is not in the current file, but in an include:[] file.
I guess I could just look to see if either ./images or ../images exist, and assume that.
I'm not sure yet how I'll decide what type of object is being dragged in (probably by the extension with a configurable list somewhere).
If the object being dragged in is not an image, then what? Just compose an include:[] for it?

[tajmone]

I've never seen drag'n'drop functionality in ST packages, nor I recall reading anything about it in the ST API (but I'm not an API expert). Since Sublime Text 4 is still a new product, who knows ... maybe we'll see this implemented.

You can drag and drop a document or image into ST, and it will be indeed opened according to the supported formats.

If the ST API allows hooking into the drop functionality, then it should be indeed possible to achieve what you propose, so it's worth looking into it — once you are able to intercept the image being dropped, and the context of the panel where it's being dropped into, then it should be possible to intervene via a custom Python plug-in — the big question is whether drag'n'drop functionality is just handled by the OS native functionality, or whether it's captured by the ST API (I have no clue whatsoever).

I agree with you, it would be really cool to have that.

[polyglot-jones]

I got something usable worked out!

1. Drag one or more images to Sublime. Sublime will display each image in it's own tab.
2. Switch back to the tab with your AsciiDoc document.
3. Invoke my gather_images command. It will:

a. Make a list of all of the file names of the open image tabs.
b. Close those tabs. All non-image tabs are left alone.
c. Insert "image::C:\folder\image.jpg[]" into the document at the cursor -- one line per image.

This is all working. What I don't have working yet is changing the names to relative paths (per the :imagesdir: if there is one, or relative to the document itself).

Any comments, questions?

[tajmone]

Lacking a way to directly hook into drag'n'drop functionality via the API, this is probably a viable solution, after all most users won't be opening images in the editor just for previewing purposes, so it's reasonable to expect that this is unlikely to interfere with any images related operations (also, it's a non destructive operation, it just closes tabs).

I haven't had a chance to look at the ST API Reference to see if there are any functions that might come to our aid in this respect, but even if they are they might not be documented (ST3's API was never fully documented in the past, so we shouldn't expect any API will ever be). At least, now the ST docs have been unified to cover all ST incarnations, and you only need to click on the version label to filter which version to show (and of course, there is a ST4 label, even though we're constantly reminded that "there's no Sublime Text 4, it's just Sublime Text!" 😉).

Any comments, questions?

I'm concerned about the Windows paths, which won't work on other OSs. Using forward slashed / as dir separators instead of \ would fix part of the issue (since Win is OK is both), but this only concerns the use of relative paths really, since absolute paths would make the documents specific to a user machine anyhow.

This is all working. What I don't have working yet is changing the names to relative paths (per the :imagesdir: if there is one, or relative to the document itself).

That's going to be tricky, especially in projects hosting multiple documents, since each doc could have its own images folder.

Probably, a better approach in this case would be for the plug-in to provide the user with a dialog window, allowing to choose the source directory containing the images.

As for the imagesdir attribute, it gets defined in every document (either implicitly, with a default value, or by the user in the source doc or via CLI options), so it's safe to assume that all image files would be looked-for in that folder, so the plug-in could just strip the directory path and keep only the filenames.

The problem is that this might also strip important subfolders info (i.e. relative to ./{imagesdir}/), unless the above mentioned dialog is used, allowing recursive search, in which case the plug-in would know to preserve subfolders info.

Even if this functionality doesn't result in perfect paths, it would still lift a significant burden on authors, which would only have to fix a few images paths here and there in the generated ADoc — e.g. to strip the path is easy since all images will most likely share a same path, so just select C:\folder\, press AltF3 and then Canc, and all paths are gone at once (no big deal in terms of work to be done).

Probably starting off with a simple concept that leaves the door for future improvements is the best approach, i.e. ensuring that those improvements won't change the way the tool is used, but only improve quality of end results (or, if a UI dialog is used, allow for new options in the UI).

[polyglot-jones]

I'm concerned about the Windows paths

That's not me. I just used whatever ST told me that the image's file name is. If you're on a mac it'll be forward slashes.

Even if this functionality doesn't result in perfect paths, it would still lift a significant burden on authors,

So, yeah. Full paths for now.

[tajmone]

That's not me. I just used whatever ST told me that the image's file name is. If you're on a mac it'll be forward slashes.

Yes, but Asciidoctor works best with Linux style paths, and then Ruby will handle them according to OS, which means that the source document will work on any OS. Of course, this might not work with absolute path, since drive letters are handled differently by different OSs.