GNOME Bugzilla – Bug 152993
New documents/folders are not created under the mouse position
Last modified: 2008-11-26 22:24:52 UTC
When you want to create a new document, right clicking on a free desktop area, the document icon is not positioned under the cursor, it's created in a free desktop region, that could be under other windows. I think that the right behaviour would be that the new document icon should be created under the position of the right click. It's annoying have to look for the new document under all the windows to manipulate it.
*** Bug 153568 has been marked as a duplicate of this bug. ***
Also applies to new folders, updating summary.
This also applies to files that were dragged to the desktop / folders. FWIW this is _really_ annoying for me, as I always covering the left monitor, which is where the files appear.
*** Bug 302919 has been marked as a duplicate of this bug. ***
Crispin, do you still have this issue? That works fine for the dnd to the desktop here
This does seem to work fine for me now.
It definitly doesn't work fine. I've got a patch which solves this for new documents from template, but the new folder thingie seems to be a bit more tricky, since the current IconPositionIterator architecture only provides source URI iterators. I've hacked it to accept target URI iterators as well but duplicate handling is broken them. Let's see what I can do... .
Another example of it failing to put the new file under the mouse cursor is when dragging the image off the gnome-panel-screenshot program onto the desktop. No matter where you drag the image, it always appears in the top left of the screen.
Is this bug related to #145000 and #45368 ?
Lionel: Both are sort-of related. While bug 145000 describes the same issue as here - but only complains about folder creation, I think we can close it. Bug 45368 refers to the internal manual layout icon container code borkage, though. The issue won't be there anymore after we fix this one.
Oh, and note that I already had a patch for this in my local repository, but the patch didn't deal correctly with folders. The problem is that the icon positioning code works with source URI iterators, which makes it hard to deal with folders that have a source URI set to NULL. I think we should simply remove the URI code from the iterator. The index should just match the position of the positioned icon in the icon list.
*** Bug 145000 has been marked as a duplicate of this bug. ***
Is fixing this something that would still be possible within the 2.14 release schedule? I run into this all the time with new documents and would much appreciate it if there's any possibility of fixing it.
An anylsis showed that we're currently (Nautilus 2.13) having two problems: a) icon positions not correct - resolvable by converting the GdkPoint coordinates on screen into eel canvas units b) icon positions not set for newly created files. Problem: We copy over metadata from the old "/tmp" location where we create a dummy file, which overwrites the previously set icon position. I've tried to resolve this by hacking the metadata system, since I supposed the problem is due to the async nature of the lazy metafile reading. However, it turned out that this is not resolvable without a special file transfer hint specifying to NOT copy over metadata.
*** Bug 330376 has been marked as a duplicate of this bug. ***
It's not only documents or folders that should be created under the cursor. When selectgin "Open Terminal" from the context menu it can be thought of as "creating" a new terminal. Thus even this form of "creation" should behave as expected.
(In reply to comment #16) > When selecting "Open Terminal" from the context menu it can be thought of as > "creating" a new terminal. I don't they should act as the same manner. A terminal is an application and so, should behave following WM rules (creating windows from left to right), whereas the files are object on a desktop.
From a certian point of view that is a correct techincal distinction. Dropping the knowledge of this distinction puts the matter in a different light though. The actions are similar: 1. You right click and select a menu entry. 2. A new object appears on the screen.
I note that this bug is listed as status "NEW" and yet, as of my nautilus-2.14 system, it seems to be fixed! (Thanks!) Is anyone from gnome-landing going thru these bugs and closing them?
(In reply to comment #19) > I note that this bug is listed as status "NEW" and yet, as of my nautilus-2.14 > system, it seems to be fixed! > New folders are created under the mouse cursor, but new documents are not (as of 2.15.2).
Is there any chance a fix for this will make it into 2.16? This is one of those niggling little usability issues that long-time Gnome users work around (though it's an annoyance no matter how long you've used Gnome), but that throws new users off. It's the creation under other windows aspect that's the killer -- if you don't already know where to look you could think this feature is completely broken, then an hour later after closing Firefox or OpenOffice wonder why this "new file" appeared out of nowhere.
I'm not sure when this was fixed, but as of nautilus 2.17.90 it's fixed for documents as well as folders.
Closing; this doesn't happen anymore.