Re: [Nautilus-list] Using drag and drop to copy files in Nautilus?

[Jonathan Blandford <jrb redhat com>]

Darin Adler <darin bentspoon com> writes:

> On Monday, July 30, 2001, at 08:43  PM, Benjamin Kahn wrote:
> 
> > Take two -- this patch applies a little better, and it fixes a problem
> > with dragging files to the desktop.  (It would create a link file first
> > and then try to copy the file.  This would popup a warning dialog during
> > every drag.)
> 
> What I said earlier to Jonathan was wrong. Let me try to explain the
> situation.
> 
> Right now, the code to handle dropped icons is in
> nautilus_icon_container_receive_dropped_icons. This is incorrect,
> design-wise, because the icon container is not supposed to be file
> manager specific. The code should be in FMIconView or FMDirectoryView
> (FMIconView'
> s superclass).
> 
> The code to handle dropped lists of URIs was accidentally never
> written! Instead the icon container sends a handle_uri_list
> signal. This is a good idea, because it goes in the direction of
> putting the code in FMIconView or FMDirectoryView, but it's silly to
> do it right with a signal for URI lists, and to hard-code it for gnome
> icon lists. So I recommend we get rid of the unused signal for now and
> add more code to nautilus-icon-dnd.c to handle the URI list case,
> based on what nautilus_icon_container_receive_dropped_icons does.

Okay -- I can probably do that.  It doesn't sound very hard.  The only
question is does the desktop's handler exist for any special reason?

> eel_list_drag_data calls eel_drag_build_selection_list for both the
> gnome icon list type and the URI list type. The
> eel_drag_build_selection_list assumes the icon list format. Of course,
> the code that knows about file manager details should not be in Eel,
> since it really belongs in FMListView or FMDirectoryView, not EelList
> at all.

Dragging into a list is sort of painful anyways.  There isn't any 'dead
space' to drop it.  For example, you couldn't drag a file into a
directory just containing a bunch of directories -- you would end up
dropping it into a directory itself.

> I'd like to see another try at fixing this that shares more of the
> existing code instead of writing so much new code.

Hrm.  I can get rid of the "handle_uri_list" signal and try to handle
uri-lists in nautilus-icon-dnd.c.  However I'd like to see consistent
logic in all file views if possible, and I feel insufficiently oriented
with the code to know where that should go, and I certainly don't have
time to write/test it before the next RH release.

Thanks,
-Jonathan