Drag 'n Drop in list view doesn't work

Thanks for your bug. i don't understand your description. If you drag something to a folder in the list the icon is changed to an open folder and you can drop it to that folder, what else do you expect?

I must apologize. I just came home from work and decided to try it again myself. The three bugs I posted were from a scribble I kept, intending to send them for quite some time now. Apparently this 'bug' was for Breezy (or I just did something wrong when I wrote it down), but I tried to drag a file into Nautilus in list view (not in a folder, but drag it among other files), and I could with no problems at all. So again, sorry for your precious time. I'll be more careful next time I file a bug.

Keep up the good work!

No problem, marking that one as fixed then!

This bug is not fixed, it should be reopened, and is in serious discussion upstream.
In gnome 2.22, take nautilus, put into list view, go to any directory where are more files one nautilus screen can display, so the scroll basrs appear.
Now take a file from otherwhere and try to drag&drop it into the CURRENT directory in nautilus -sit is not possible, you can just take the subdirs.

There is no "white gap space" like in symbol view.
That should definitely be possible for a modern file browser.

I agree with Christian A. Reiter
What's more, there's no "paste" when you right click anywhere in list view EXCEPT in the blank space BELOW the files if there is few items in the folder.

I just retested it in my Hardy beta system. Dragging a file into Nautilus in list view is perfectly possible. The file is inserted among the other files just fine (even if the window is completely filled with files (scroll bars appear)). Perfran is right that in list view there is no right-click - paste option. Also selecting multiple files by 'lassoing' over them is impossible in list view (but thats the other bug). So you guys are right about not closing this bug entirely - not all issues are resolved...

No, that's misunderstood...
What does NOT work is drag a file into current folder if that folder has many subFOLDERS, not FILES. When there are files itworks. But when there are subfolders there is no space for the current one.

Ah, finally I get what you are saying (pardon me being slow ;-)). Yes, that is not possible now. I've grown a habit of working around this behaviour but it sure is annoying and unintuitive.

re opening, still an issue with hardy.

I experience this as well, but not with the limitation others have mentioned of having to have lots of items to fill up the list view. For me, I can't drag and drop to any folder in list view, no matter how few items are in it, at least with file-roller. Changing to icon view allows me to drag and drop just fine.

While Goswin's other issue of not being able to drag to select files ("lasso'ing") may be a separate bug report, I wouldn't be surprised if it was somehow related, as with the right-click issues. Overall, something funky is going on with the unused portion of the window (where there aren't icons) in the list view, and the view in general.

The file-roller issue is a another bug in nautilus: https://bugs.launchpad.net/nautilus/+bug/185387

Still no drag-and-drop in list-view in nautilus - this is especially frustrating in combination with file-roller.
There seems to be another bug report in gnome bugzilla at http://bugzilla.gnome.org/show_bug.cgi?id=101938
A patch is attached, but it doesn't seem to be integrated into upstream that soon. Fedora10 will include it, so can ubuntu include it too?

why would fedora uses the patch and not upstream if it's correct?

Because the Gnome people are slow?

the bug tracker is not the right place to start trolling could you consider your comments usefulness before sending one?

> why would fedora uses the patch and not upstream if it's correct?

You questioned the correctness of the patch because gnome hasn't included it yet, didn't you?
This wasn't meant as an offense, it can take a while to get a patch into gnome. Even when it's correct, i guess.

Ok, they are not slow, they are just overburdoned.

>What's more, there's no "paste" when you right click anywhere in list view EXCEPT in the blank space BELOW the files if there is few items in the folder

I think the problem is that a full selection (1st -> n'th columns selected) is strictly used in nautilus.
It makes it difficult to get hold of right click actions like paste, create document, create folder etc, when in the "view as list" mode.

I think, if a right click action happens on the "name" column then it should only show the actions present on the current selected folder/file in the context menu. If the right click happens on the other columns then it should show the actions that one would expect when right clicking in white space.

------------

Drag and drop senario should just work like it does when you drag and drop a folder into the bookmark panel: If the drag hovers directly over a bookmark it is considered a copy and if the drag hovers "in between" two bookmarks then you get a "line" indicator between the two to show that you are about to create a new bookmark in between.

Therefore to keep things consistent just do the same when you drag a folder or file "in between" two folders (when in "View as List" mode.)

Both of these issues (the drag-and-drop of files/folders and the right-click context menu in full list-view) have bothered me for a long time; there is still no solution in Ubuntu Jaunty.

This is certainly a large usability issue, but it is certainly not trivially fixable; therefore it is not a paper cut.

David, can we have a second look at it and for now reconsider as paper cut - it is quite a painful issue and worth reviewing for Karmic cycle. It could be too big for this project, but let's keep the discussion alive.

During our recent usability tests one of the subjects (an accountant, using Windows/MS Excel daily) had huge problems with dragging and dropping a file (exactly as described here) and, after about five minutes of trying - already very frustrated - had to revert to right-click copy and file>paste to finally succeed. I don't have to mention that by that moment his opinion about Ubuntu had already been formed.

Issues like that hurt Ubuntu's reputation greatly. I was surprised seeing this bug's priority set to "Low", this is certainly a high-priority issue.

i completely agree with Mat. This issue has been one of my biggest pet peeves and I don't see why this problem is any more difficult than the current "high priority" paper cuts. Many of the confirmed paper cuts are hardly trivial fixes either. Thanks for your time.

I agree that always having some usable white space in list view is very important. My usual workaround is to view the parent folder of the folder that I want to drag to, and then drag to the folder's icon, or right click it and select paste into folder, but having white space is useful for other reasons as well. I frequently create new folders or files through the right-click context menu, and this is not possible on a full list view, so I have to use the main window menu.

One solution would be to do something similar to Windows Explorer, where only the actual file name is an active object, and the rest of the details are just non-interactive background text (even the blank space within the name column is non-clickable). I think there are some definite improvements that could be made over Microsoft's implementation though, for example having a light outline and highlighting around the filename to indicate the interactive area. Also, it would be nice if the interactive area was always at least 1/3 or 1/4 of the name column's width, so really short filenames don't get accidentally missed when lassoing a bunch of files. One other MS flaw that should be avoided is that in Windows Explorer, the interactive area is often smaller than the actual filename text, maybe because I use a non-standard font in Windows, I don't really know.

The "Unable to drop to current folder in nautilus list view" has been an open bug since late 2002.
http://bugzilla.gnome.org/show_bug.cgi?id=101938
When I first read about Papercuts this was what immeadiatly came to mind as it is a design related issue in a very central part of GNOME. It is precisely the kind of bug that requires a feature focus instead of a package focus. This, and the fact that you can learn to work around the issue is probably why it is still an open bug since 2002.

I am reattaching an illustration by Felix Rommel from the GMOME bug as I think it is good for basing the conversation around.

Both steps 1 and 3 in the picture Sebastian Bengtsson attached allow me to drop a file into the current folder in nautilus in list view.

So this works for me in Jaunty... have I got this wrong? Is there some feature I am overlooking missing?

Lightbreeze: Try dragging to a spatial Nautilus window filled with subfolders in List View, instead of a File Browser window. I think you'll find you can't, not even in Jaunty.

Yes, I see. Definitely annoying.

I think this not a paper cut as Ubuntu doesn't use spatial nautilus by default, but I'll leave that decision to someone else.

Note that this is not about spatial mode (like explained here http://www.bytebot.net/geekdocs/spatial-nautilus.html ).
It's about plain, simple list view.

I'm sorry I must have read the description without realising the point it makes -> that this is for a folder full of sub-directories :=). *face palm*

I second this bug, this has been a source of endless annoyance for years!

I don't like to use the words Windows and Usability in the same sentence, but they've actually solved this user interface idiocy very easily by the DnD selecting the folder you're in (not any of the subfolders) when you move the mouse to a column different from the "name" one, i.e. every other column (type, date, permission, owner, group, etc.) is treated as whitespace for DnD.

This makes sense because you're no longer pointing directly at a directory where you want to drop the files. The error Nautilus makes is to assume that there is an invisible row all the way across the interface. Which means that when your DnD is pointing at for instance the 'type' column, Nautilus is still going to drop your files in the folder that the row corresponds to.

I confirm that too - it always annoys me.
Waiting obsessively for a fix!

This problem needs to be fixed asap. If we're talking about usability, this could be a crucial turnoff for people new to Ubuntu. I would certainly rate this as __the__ biggest annoyance in the Ubuntu user interface (being a user of list view). The solution is to make every area of the window into drag 'n' drop "whitespace", apart from the file/folder names. This is how Windows does it, and I cannot think of any better way.

Please can someone pick it up? It really begs for a fix....

ALso when you copy a file and try right mouse click to paste a file, the option is not there because there is no "whitespace" as in the compact view. Very annoying indeed.

Looking at the screenshot in comment #24 and option 1 works for me now. (Both as a drag & drop and as a right-click target.)

This still leaves the lasso issue, and the fact that dropping/right-clcik inside the main pane don't work (which people expect).

Jan, as I tried to point out in comment 26, if Nautilus is *not* in file browser mode, the "option 1" you reference is not available. See attached screenshot. Given the window in that screenshot, I can *only* drag a file to a subfolder of 'mp3', but not to 'mp3' itself. :(

Option 1 is also not at all obvious. Many people migrating from Windows will be expecting to be able to simply drag and drop into the main area, and to be quite frank I would expect that as well. Additionally, what if the current path is not in "button" mode but in "text" mode; is it possible then?

Obviously option 3 would be a big step up from the currently functionality, but still it would be inferior to the Windows implementation. In Windows the only non-whitespace is the area occupied by the filename, not the entire filename column; imagine if you turned off all columns except the filename column, the problem would still be there since option 3 is not possible.

@Mathew: Looks like you have disabled the address bar, enable under menu "View" to get Option 1 back

@Jakob: Same screenshot, this time with View menu exposed. What are you suggesting? There is no such option when Nautilus is in non-browser mode.

Same problem but from the paste point of view rather than DND approach, has some people's attempts at fixes and a link to the upstream bug:

https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/51043

It's clear that this is a big usablity issue, and I join those calling for the 100 papercuts project to fix it (please?)

the hundredpapercut points usuability issue but doesn't get those solve in a magic way, this bug is not trivial and will need a nautilus hacker to work on the issue

<rant>
This issue has been solved decades ago by the same engineers who designed one of the first successful GUIs: the Macintosh. IIRC this feature was available ever since I remember using a Mac, and that means ~ Mac OS 6, in the late 1980s.

It is a shame that in 2009 we're having this discussion. Anyone who cares about user interfaces should study the history of the Macintosh.

It's fine to evolve new features if they don't exist in previous works or if the alternatives can be made better. But if they just work, and are almost perfect, you just copy them. Why try to change the behaviour of the Mac OS Finder in this respect? Drag and drop in the Mac is the example that all OSes should follow. Anyone trying to come up with something better should think twice, and present strong arguments.
</rant>

In the Mac, dragging a file to a window containing other folders (in any view: list/icons) just works because there is always "white space" anywhere ... only the icon (or in a list view, the leftmost column) is the object that gets highlighted (activated) upon passing the mouse over (or when dropping a file). If you don't want to drop a file in a subfolder just drag it elsewhere.

In gnome, I guess that the essential mistake is having the space in the list view be treated as a table with rows = files or folders. The consequence is that there is almost no neutral places in the window (non-objects) to drop files to.

This should not be marked "Invalid". The issue is still present in Ubuntu 10.04.

The 'invalid' status is misleading. The upstream bug being tracked was marked as a dup. I'm updating it to track the new bug.

<rant>
Reported in September 2006 and still present a full four years later in October 2010 in Nautilus 2.30.1.

What I hate most about these kinds of stupid little bugs in the time wasted before realizing it's a bug. I've previously changed the background in Nautilus. Tried to do it today on another computer. Eventually realized it was in list view. Searched. Found the bug. So much wasted time by so many people. Completely out of proportion with the time I expect it takes to actually fix the bug.

I know it's a small issue, but if GNU/Linux/FLOSS/GNOME/whatever can't get these kinds of things right, then rather don't implement them in the first place. Nothing is better than half-baked with bugs.

I'm also tracking a bug with Nautilus where the "name" column can't be resized. And third-party "hacks" are required just to show the duration of an MP3 in a column in Nautilus. I love GNU/Linux/FLOSS/whatever 99% of the time. Just not right now. And just not when my time gets wasted.
</rant>

how is this not fixed yet? ...
not unique to nautilus. most file browsers have this issue (windows 7 decided to implement this bug again - maybe XP worked too well).

With Nautilus 3.2.1 which ships in 11.10 as a part of Gnome 3, I am able to easily place items into folders in list view. Are you still have a problem here?

Chris Wilson: read the description again. It is not about placing items into subfolders in a folder but it is about placing items into said folder.

ACK. Still valid in gnome3, nautilus 3.2 and ubuntu 11.10.

Ah, sorry about that.

If this is going to be fixed, there is a patch in the upstream report (but fairly old I am afraid), by the way.

that's not a papercut bug, it's open for years for a reason, it's non trivial to solve