GNOME Bugzilla – Bug 47944
Pasted files do not appear near mouse pointer
Last modified: 2012-08-13 22:40:45 UTC
When you paste file(s) through a context menu, Nautilus doesn't place the icon(s) next to the pasting point. In contrast, Windows Explorer allows users to move files' icons through Cut and Paste. * REPRODUCIBLE: Always * STEPS TO REPRODUCE: 1. Right-click on a file or folder icon on your desktop, and select "Cut File". 2. Right-click elsewhere on your desktop (or in a manually sorted folder), and select "Paste Files" * ACTUAL RESULTS: a) If you paste a file in the same directory that you copied it, absolutely no feedback occurs that Paste operation occurred. Had you done this on Windows Explorer, the icon would have been moved across the desktop, and placed at the location where you clicked Paste. b) If you paste in a different directory, the icon is placed (I think) in the bottom-most available position in the folder, rather than at the location where you clicked Paste. If we're adopting this Windows behavior to make Nautilus friendlier for people coming from that mindset, I'd suggest adopting it in full, rather than introducing various slight deviations that may confuse users. ------- Additional Comments From snickell@stanford.edu 2001-07-23 00:33:03 ---- Taking bugs previously assigned to Pavel, assigning them to myself. Will parse them out at my leisure , but many are GnomeVFS bugs we should look at for 2.0 ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 21:19 -------
Changing to "old" target milestone for all bugs laying around with no milestone set.
Still there in 2.1.2 - given the lack of discussion I'm moving off to "future"
*** Bug 142879 has been marked as a duplicate of this bug. ***
Most of the time this isn't relevant at all, because we use auto-layout which automatically sorts the entries. When using manual layout (used on the desktop at least), it would be nice to have this "spatial pasting", though. I think I still have code for this. The main issue is that the icon position iterator uses the source URI as a hint where the position is stored in the icon position array, which is NULL for newly-created folders. I've hacked the iterator to be able to take target URIs into account as well, but the issue is that this doesn't work for name conflicts, since the newly-created folder will be assigned a new name. We could either change the URI in the position iterator, or remove the uri references from the iterator struct, using only an index which is increaes for each transferred file.
Created attachment 51060 [details] [review] Proposed libnautilus-private/ patch
Created attachment 51061 [details] [review] Proposed src/ glue These two patches fix the issue at least for the creation of files/folders. I've also submitted them to the nautilus mailing list [1] for review. [1] http://mail.gnome.org/archives/nautilus-list/2005-August/msg00192.html
This bug is many years old, so it doesn't block the release. We'll get back to this bug after the release.
*** Bug 317496 has been marked as a duplicate of this bug. ***
I commited mannys patches, but we still don't get the position right on paste.
Came here from Launchpad 22730 (https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/22730) via Gnome Bug 317496. I suppose they are marked duplicate as it has to do with position, but what I'm interested in is not pasting into positions but rather newly created documents and folders as those bugs are about. I often create new documents to take a note or similar and then I have to type the name and activate the file blindly or minimize apps that are blocking. In the beginning this resulted in quite a few empty files too, as I thought nothing happened. Just wondering what the status of this is?
*** Bug 446261 has been marked as a duplicate of this bug. ***
*** Bug 601993 has been marked as a duplicate of this bug. ***
This implies doing manual positioning in all folders. I don't think we want this. What we do already is ensure that the newly pasted file is scrolled into view.