Re: PATCH: use local path when dropping files onto icons

[Frank Worsley <fworsley shaw ca>]

> I prefer not to add that hack, since:
> a) It could potentially breaks some app that only handles URIs.

I don't think that's the case, I tired it with a few apps.

> b) Having the hack means there is less chance of someone doing the work 
> needed for the correct solution.

I'm on it and I've got it implemented for %f, %F, %u and %U. :)

In the case of %f and %F I only pass in the URIs that represent a local
path. If any non-local URIs are included I display a message box to the
user informing them that the drop target supports only local items and
that they should manually copy the items to a local destination and then
drop them again (in case of multiple items I still open the ones that
were local). Is that acceptable or should I automatically copy the items
to a temp folder and open them (as indicated by the desktop file spec)?

I personally don't think automatic copying is a very good idea since I
might make changes to a file, save it and then assume the remote copy
has been updated when in fact it hasn't. Of course I could display a
message box letting the user know the item was automatically copied, but
I could still see myself screwing up.

Also, I am not clear about the meaning of %d and %D in the spec:

%d - the directory of the file to open
%D - a list of directories

Does this also include remote directories? Can %d and %f appear in an
Exec string at the same time or are they mutually exclusive? I assumed
%f, %F, %u, %U are all mutually exclusive. In case only %d appears and
the user drags a file onto the launcher, do I display an error message
to the user saying the drop target only supports directories, or do I
strip the filename off the URI and use the basename as the parameter?

Any comments are welcome.

- Frank