After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 101938 - Dropping in to list view awkward
Dropping in to list view awkward
Status: RESOLVED DUPLICATE of bug 310819
Product: nautilus
Classification: Core
Component: Views: List View
2.11.x
Other All
: Normal minor
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 94619 312406 313566 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-12-25 10:23 UTC by Pim van Riezen
Modified: 2010-05-03 00:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Drag 'n' drop impossible in list view (116.47 KB, image/png)
2007-06-16 07:38 UTC, tmp
Details
Make right columns "insensitive" (139.36 KB, image/png)
2008-12-21 18:08 UTC, tmp
Details

Description Pim van Riezen 2002-12-25 10:36:40 UTC
Package: nautilus
Severity: normal
Version: 2.1.5
Synopsis: Dropping in to list view awkward
Bugzilla-Product: nautilus
Bugzilla-Component: View as List

Description:
Description of Problem:
It is near-impossible to drop a file into a folder that is in list view
and contains only subdirectories.

Steps to reproduce the problem:
1. Create a folder with a number of sub-directories, enough so that the
   list view will have to scroll.
2. Try to drop a file or directory from another window or the desktop
into
   the list.
3. Cringe as you cannot get the file not to drop into one of the
sub-directories

Actual Results:
File ends up in a sub-directory

Expected Results:
File ends up where I wanted it

How often does this happen?
All the time

Additional Information:




------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-12-25 05:36 -------

The original reporter (pi@madscience.nl) of this bug does not have an account here.
Reassigning to the exporter, unknown@bugzilla.gnome.org.
Reassigning to the default owner of the component, nautilus-maint@bugzilla.gnome.org.

Comment 1 Dave Camp 2003-03-10 22:44:21 UTC
you can drop to the column headers.

I can't think of a better way to do this, suggestions are welcome.
Comment 2 Murray Cumming 2003-07-28 14:57:15 UTC
I wonder what the Mac does.
Comment 3 Pim van Riezen 2003-11-13 21:24:59 UTC
For what it's worth, MacOS X uses a small region of, I would guess, two pixels 
between rows of a column view that will not 'highlight' either row as a drop target. In 
unsorted listviews, this is used to move items between two existing items. In the 
Finder, it results in copying/moving the file to the containing folder, not either of the 
two folders in the rows surrounding the cursor.

Cheers,
Pi
Comment 4 Timo Aaltonen 2003-12-22 18:37:25 UTC
in winxp to drop the object in a directory all you need to avoid is
dropping it on top of the name of a directory (or an archive, which
would add the files in it =). As I see it, fixing (/changing) the way
gtk+ handles selections in list view (GtkTreeView??)
could help getting similar behaviour.
Comment 5 Tim Herold 2004-05-08 16:52:33 UTC
*** Bug 94619 has been marked as a duplicate of this bug. ***
Comment 6 Sebastien Bacher 2005-08-15 22:25:05 UTC
*** Bug 313566 has been marked as a duplicate of this bug. ***
Comment 7 tmp 2005-08-16 13:53:26 UTC
> "you can drop to the column headers."

OK that works but this is very unusual and this does not solve the problems:

http://bugzilla.gnome.org/show_bug.cgi?id=94618
http://bugs.gnome.org/show_bug.cgi?id=138931

With a proposal of comment #4 you could solve all the problems at once.
Comment 8 Christian Neumair 2005-08-17 13:07:42 UTC
Summary:

We have two possibilities to tackle this issue

(I) allow to drop "between" two rows. I've submitted a patch for this to
nautilus-list [1,2], which might make it into Nautilus 2.14.

(II) allow to drop in other columns than the name column to paste to the
background. This would mean that other columns are not treated as belonging to
the file. While this is possible as well, I fear that

a) it looks odd that the whole row is highlighted as drag feedback, while the
highlighting is only drawn if you hover the name column. Changing this would
require GtkTreeView changes (_set_drop_column). This is feasable only for
Nautilus 2.16.

b) it may feel inconsistent with other applications' treeviews

On the other hand, treating other columns than the name columns as not belonging
to the file (i.e. acting as background) could work pretty well if we also treat
clicks to those columns as background clicks.

[1] http://mail.gnome.org/archives/nautilus-list/2005-July/msg00260.html
[2] http://mail.gnome.org/archives/nautilus-list/2005-August/msg00078.html
Comment 9 Martin Wehner 2005-08-19 23:24:49 UTC
*** Bug 312406 has been marked as a duplicate of this bug. ***
Comment 10 tmp 2007-06-16 07:36:12 UTC
This bug got even worse in 2.18.0.1 / 2.19.3:

Now it is IMPOSSIBLE to drag'n'drop a file even to column header as suggested in comment #1.

See attachement.

Please improve list view in Nautilus - maybe it's not for beginners but I think many to not want to miss a proper list view implementation in Nautilus.

What's about the suggestion from comment #4? Is it possible to change GTK list view that only the "Name" column is activated when hovering over or right clicking it?

Shall I open a new bug report for versions 2.18.0.1 / 2.19.3?
Comment 11 tmp 2007-06-16 07:38:05 UTC
Created attachment 90046 [details]
Drag 'n' drop impossible in list view
Comment 12 Dimitri Benin 2008-10-17 05:37:58 UTC
I'm currently working on it, will be ready by this weekend.
I still have one question about how to implement this functionality for one special case. For example one opens a folder in list view. Inside of this folder a subfolder gets expanded, so that one can see the files inside of this subfolder. Now if a drag occurs to one of the subfolder files (not folders), where should the dragged file be placed, into the subfolder or into the folder the window was opened for?
Comment 13 Alexander Larsson 2008-10-17 13:43:18 UTC
Dimitri: Into the subfolder seems to make most sense. Assuming you mean on the filename column. For the other columns it seems to make more sense to go to the toplevel dir, i think.
Comment 14 tmp 2008-12-21 18:08:20 UTC
Created attachment 125101 [details]
Make right columns "insensitive"
Comment 15 tmp 2008-12-21 18:09:04 UTC
Hello Dimitri: Thanks for your improvements in list view mode in Gnome 2.24! :)

Is it possible to make the right columns beside the name column "insensitive"?

That would be great because you would be able to drag and drop files/folders there. And it would be possible to click with the mouse on the area and highlight the files which should be marked (see screenshot above this post).
Comment 16 Dimitri Benin 2008-12-21 20:33:32 UTC
(In reply to comment #15)
> Hello Dimitri: Thanks for your improvements in list view mode in Gnome 2.24! :)
> 
> Is it possible to make the right columns beside the name column "insensitive"?
> 
> That would be great because you would be able to drag and drop files/folders
> there. And it would be possible to click with the mouse on the area and
> highlight the files which should be marked (see screenshot above this post).
> 

I have now working code which makes DND possible, it will only drop something into a subfolder if one drags the items onto the name column. However, I spoke to Alexander Larsson on irc, he said that I will also have to patch the selection so that only the name column is selected during a drop to the name column. And right now I'm stuck with this (it's tedious to find out how it works to be able to patch it) and did not have time in the last couple of months. 
Comment 17 Jakob Unterwurzacher 2009-11-04 00:34:31 UTC
Dimitri Benin, would you post your code? There is quite a lot of demand in Ubuntu's bug tracker ( https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/61237 ).
Comment 18 Cosimo Cecchi 2010-05-02 23:18:19 UTC
Bug #310819 has a patch, closing this a dup.

*** This bug has been marked as a duplicate of bug 310819 ***