Drag&Drop to jAlbum

[Photon]

Edit 2014-01-28 19:55: Looks like a basic LINK drag&drop issue not only to jAlbum. See later postings.

There is a problem with Drag&Drop from IMatch v3.6 and 5.0 to the web page photo album creation software tool jAlbum, www.jalbum.net. On my Win7pro32bit system it does work, but on another Win7home64bit and a Win8.1pro64bit it does not. Nothing is dropped to the target application jAlbum. Drag&Drop from WinFileManager to jAlbum does of course work on all Win systems.

jAlbum is really wonderful to be used together with IMatch, because transfer of all DAM results (portfolios, categories, filtering, search, ...) from Imatch can be transferred to jAlbum very convenient for online publications. jAlbum can link to original files which are managed by Imatch, which does not waste storage and does allow convenient update of image editing.

I assume that the Drag&Drop issue under Win64bit is no bug of IMatch, but has something to to with Windows or jAlbum? Are there other Imatch users who use jAlbum and can share Drag&Drop experience? If not yet, it is really worth to try it.

Martin

[Mario]

IMatch implements the standard Windows Drag & Drop HDROP protocol. This works usually without a hitch and all applications, including Windows Explorer, LR, Bridge, Photoshop, other RAW processors etc. I don't have jAlbum. Maybe you can ask the programmer of that application what he expects and why a standard HDROP is not accepted.

[Photon]

Thanks for your confirmation. There are still a couple of windows tools who have problems with Drag&Drop and it seems to be challenge to find the reason. That because three parties (source SW, operation system and target SW) have to play together. The author of jAlbum is already investigating, because he is very interested to support a good workflow from good tools like IMatch to jAlbum.

[Mario]

The author of jAlbum is already investigating, because he is very interested to support a good workflow

Very good. Since he sits on the receiving end he has the best view on the problem. When the user drags "data" from one application (IMatch) to another (jAlbum), Windows sends the receiving application certain messages. Reacting on these messages allows the receiving application to get the "list of file names" dropped by the other application, among other data. If he can look at how he handles these messages, he should be able to tell me if and what is wrong or missing. I can then try to change something or provide other help. He can contact me via my support email any time.

[David_H]

When the user drags "data" from one application (IMatch) to another (jAlbum), Windows sends the receiving application certain messages.

Could it be that one application is running either elevated, or under compatibility mode? Windows won't send the messages from a non-elevated application to one that is for security reason.

[Mario]

If Windows does not allow drag and drop, the cursor visible to the user indicates that and the application "under" the cursor will not receive messages. And the author of jAlbum would notice that (if jAlbum needs to be run in elevated mode).

[Photon]

Together with jAlbum SW author I found out the problem, which seems to be within IMatch. It is because with Drag&Drop there are usually three options Move, Copy and Link possible. You can check this with Drag&Drop from IMatch to e.g. the Windows Desktop. The additional Shift-, Ctrl-, or Alt-key together with left mouse button defines the result of Drag&Drop.

IMatch v3.6 and v5.0 do currently not support the LINK drop type. See mouse cursor which is not link type but copy type when using Alt-key. With this a third party tool automatic remembered link setting is not possible any more. That is a pitty and could be required also for other image gallery tools. The Drag&Drop from IMatch is basically a big workflow asset, because Lightroom still does not allow any Drag&Drop to outside.

I detected another side effect, that IMatch allows to move a file with shift-key to the outside world (I never need such file move). But in this case a XMP sidecar is not moved together with the file and remains orphaned in the source directory. With file copy process the ignoring of xmp sidecar can be understood, but with file move this is not good.

Are both issues to be described as bugs or feature requests elsewhere in the forum?

[Mario]

IMatch supports Move and Copy for drag and drop, to all compliant targets. It does not implement the link drop type, because that's a very special case and not needed under normal circumstances. That users want to create shortcuts or symbolic links to files in an IMatch database is rather uncommon, and more easily archived by just opening the corresponding folder in Windows Explorer.

The target application is free to interpret the dropped objects in any way it likes. The type of the drop (copy, move, link) is just a hint the source application gives the target application about the intention of the user. The user expresses his intention by holding down the <Ctrl> or <Alt> key or whatever. But that's just a convention, nothing fixed.

Windows Explorer interprets the type of the drag by copying or moving files, or by creating a shortcut to the original file in case the drop indicates that the user wants to "link" to the original file in some way.

Other receiving applications ignore the drop type completely, and just open the dropped files (most applications, actually). That's the typical "I can drag and drop files from application A to application B to open them" metaphor.

From your explanation I understand that jAlbum only reacts on dropped files if the drop type is of type "link". That would be very unusual. Can you confirm that?
Why does jAlbum not just accept the dropped files like other applications and operates on them?


2. IMatch performs buddy file operations only inside the database. Copying or moving a master file may not only require to copy/move multiple files, but also to create sub-folders, and this is not possible via drag and drop.

Another problem that cannot be solved via drag & drop is when IMatch would have to duplicate an XMP file. If you move a file A.RAW which has A.XMP to another folder, but there is another file in the original folder which also refers to the XMP file, IMatch has to retain a copy of the XMP file in the original folder despite the A.RAW is moved together with the XMP. Not possible via the drag and drop protocols.

If you want to copy or move files which have one or more buddy files assigned, don't do this by just dragging the file to a Windows Explorer window. Instead perform the copy/move inside the IMatch application, where IMatch has control over the whole process.

[Photon]

Thank you Mario for details,

with current IMatch drag&drop behavior for XMP sidecars I am fully happy. You explanation of related issues is quite clear. There would be no need and sense to change anything. Like most other IMatch user I do practically all the file MOVE or COPY processes inside of IMatch.

With LINK type drag&drop there is a certain IMatch issue, because from DAM to other tools a link to original file instead of a file copy is very very important. I do not like the duplication of files for generation of galleries, multimedia shows and so on. A link/reference to one original location is better. This is also beneficial, when image files are updated (e.g. JPGs through RAW editor export). Currently you cannot LINK with drag&drop from IMatch to other windows applications. Am I wrong with this? The Alt-key is not working together with left mouse button drag&drop. Alt-key is not different from Ctrl-key with IMatch. Apparently you can only MOVE or COPY with the Shift- or Ctrl-key from IMatch.

jAlbum can operate in two drag&drop modes:

• The first manual mode offers a COPY or LINK decision box, when a file is dragged&dropped from any other application including IMatch. This works well with IMatch. jAlbum allows to remember this setting for any future drag&drop (this results in operation mode 2).
• The second very convenient automatic mode realizes COPY or LINK, when the source application does support COPY or LINK. Since IMatch does not support LINK therefor the drag&drop with automatic LINK mode fails.

There might be a chance that jAlbum can correct this in future releases. But the basic Imatch problem is still there, because you cannot create links (shortcuts) to original files e.g. to file manager or desktop via simple drag/drop with pressed Alt-key.

[Mario]

You misunderstood my post.

When an application (IMatch) drags files to another application (jAlbum) it delivers a list of file names. Optionally it also delivers the type of operation the user wants: copy, move, or link.

What the receiving application (jAlbum) does with that information is completely up to it. IMatch only sends the file names. IMatch does not copy files, or move files, or creates short cuts or hard links. The Windows Drag and Drop protocol just handles a list of file names.

All jAlbum has to do is: "Ah, IMatch just dropped these files (aka a list of file names). Now what to do with it?"
It does not have to move or copy the files if it does not need to!

For example:

+ Photoshop opens the files.
+ LR imports the files.
+ Windows Explorer copies or moves the files.
+ A browser opens the first dropped file (or all files in separate tabs)

In all cases, IMatch just sends the receiving application a list of file names in HD_DROP standard format.

[joel23]

Sorry when I interfere here, but the copy or link question is a jAlbum thingy.

Photon, I don't get your remarks about the ALT- SHIFT- or CTRL-keys. Just mark and drag & drop the images with the left mouse button pressed from Imatch to jAlbum.
You'll be asked by jAlbum if they should be added as link or as copies, which works without any problem.

See attachments: as you can see by the arrows on the images already in the project, they are linked... (copies wouldn't have this arrow)


[attachment deleted by admin]

[Photon]

I think we are all partially right and wrong or misunderstood (including myself). Probably I am a bit more wrong with some of my assumptions.
Joel23: The IMatch effect in jAlbum is only visible in the automatic drop 2 mode ("remember choice" tick box), but not in manual drop mode 1 you are referencing.

I experience, that IMatch is only able to create MOVE and COPY, but no LINK to windows desktop or windows file manager.
This with left mouse button drag&drop together with Shift-, Ctrl- and Alt-key. Isn't this missing LINK capability a fact?
This has nothing to do with jAlbum. Anyhow with the unofficial core update v11.6.13 for jAlbum this limitation was fixed.
So the issue/subject in this post is no longer about jAlbum, it is now purely about IMatch to Windows LINKs.

For me file LINKs have the same relevance than MOVE and COPY from a DAM software. Escpecially for large media files (video, audio) the file links located in other project directories are a reall must! A lot of my projects reference in their project subdirectories with individual file links to common original media files. Currently all these file links cannot be created from IMatch, but outside with each time a new windowsfilemanager window.

Example for original files and to-be-created LINKs:

• Source files (imported and managed with IMatch):
  v:\video\2013\2014-12_barcelona\20131201_1801_kx2134.avi
  v:\video\2014\2014-01_madrid\20140124_1619_kx2324.avi
  
• Target links (used from other tools, not managed with IMatch):
  c:\project\2014_spain-media\20131201_1801_kx2134.lnk
  c:\project\2014_spain-media\20140124_1619_kx2324.lnk

How to create these links conveniently with Drag&Drop from IMatch?
What about IM implementation of usual Alt-key support, because Shift- and Ctrl-key do work both as expected?

[Mario]

There was never demand to support the link Drag & Drop verb from inside IMatch.
You can create these links easily by open the corresponding folder or file via the "Open in Windows Explorer" command and then use whatever operation Windows Explorer supports to create symbolic links, hard links or shortcuts.

If you consider this missing functionality to be useful for many users, feel free to add a feature request int he appropriate board.