GNOME Bugzilla – Bug 129421
need way to easily drag folder represented by current window
Last modified: 2008-12-10 02:09:21 UTC
Description of Problem: Suppose i've got 2 folder's, A and B, opened in 2 Nautilus windows. Now, if i want to move/copy A into B, i need to go to A's parent folder, and then move/copy A to B. Suggestion of solution to the problem: It would be great if the Nautilus window had an icon representating the current opened folder, like this: http://www.iscomputeron. com/files/TrackerFolderIcon.png (see the little icon on the right upper corner) So now if i want to move/copy A into B, i just need to drag the little icon into B - no need to go to A's parent directory first.
Created attachment 24622 [details] image referred to by reporter
That's a cool idea, especially for spatial. I attached the screenshot referred to by the reporter so it's not lost, and I'm changing the Summary.
a related way to accomplish this (only if there's a location bar though I guess) is bug 40218.
*** Bug 140370 has been marked as a duplicate of this bug. ***
bug 140370 points out that there is a real problem in that the only way to a) drag the current folder, or b) get the current folder's properties, or c) perform an operation on the current folder: you have to go to the parent directory and find it, which is annoying and breaks the spatial metaphor. I mentioned in reply that it was touched upon in this thread: http://mail.gnome.org/archives/nautilus-list/2004-May/msg00032.html
So, how is this bug going on? I think that's a very important thing to have on Nautilus Spatial, it makes it much more usable.
See also bug 145400 and bug 152697.
*** Bug 166926 has been marked as a duplicate of this bug. ***
A cool idea that was proposed by Christian Neumair is to use the bottom-left drop-down menu that represents the folder in a spatial window. A patch to allow drag-n-drop of the current folder using this button can be found at : http://mail.gnome.org/archives/nautilus-list/2005-February/msg00030.html
IMHO you are making a mistake concentrating on dragging alone. The real problem is that you cannot INTERACT with open folders. Please let me explain in detail by copying a message I just posted to the gnome-usability mailing list. --- Gnome should allow interacting with open folders. What does it mean? In real life, if I see an open box of chocolates on my table, I can still act upon it: I can move it into a drawer, on in another box, or throw it in the trashcan. The fact that it's open does not limit my actions in any way. OTOH, in gnome, if I see an open nautilus window/folder on my desktop, I cannot act on it. I can only act on its *content*. If I want to act on the folder itself, I must go to the parent folder. What we need IMO is 1. Introduce a way to act on the open folder itself. Mind you: not only to drag it, but also to copy it, move it, delete it, create a link to it, etc. Simply adding a drag handle is not enough. 2. do it in a way that does not lead to menu item duplication (e.g. one menu for the folder and one for the contents). The cleanest and simplest way to fulfill the requirements is to add a way to *select the open folder itself*. Then, the "edit menu" could continue to work unmodified. For example, we could add a *button* which, once pressed, selects the folder itself. Then you keep using the existing edit menu. So we should be able to select the folder itself. But in spatial nautilus this means selecting the window! (since folders and windows are strongly indentified) So, what we really need is a button to select the open window. Where should this button be? Logically, it should be in the window's title bar. But then, we have the problem that the edit menu is located inside the window frame. To a user, it would not be intuitive what the scope of the menu is. A menu cannot act on something that is outside of it. So my proposal is: 1. add a "select this folder" button in the window frame; 2. move the nautilus menu, (at least the "File" and "edit" items) OUTSIDE the nautilus window. So the user can select the window and/or its contents, and then use the edit menu on the selection, without any logical problems.
A small consideration: The day you decided that Spatial Gnome should identify windows and folders (with a bijection), you did not realize the harsh implication of this choice: THAT THE USER SHOULD BE ABLE TO ACT ON WINDOWS JUST LIKE HE ACTS ON FOLDERS. Just as completely. So, for example, we should be able to *select* windows. Also, we should be able to *delete* them, or *rename* them, as we do on folders. By means of some kind of *menu*, not only via dragging. Possibly the *same* menu we use on folders! These requirements that clash with the current tecnhical limitations of the window manager. So the day you decided for spatiality, in some sense you condamned yourself to the problem of having to rewrite the window manager itself to make the system logically sound once again.
*** Bug 40218 has been marked as a duplicate of this bug. ***
Thanks for reporting this! With spatial Nautilus, you can drag the location button and with navigational Nautilus, you can drag the "Location:" label in the location bar. Also, both have a context menu which allow you to do actions on the open folder. This will at least work with Nautilus 2.12. Please file any remaining suggestions as new bug reports, each feature request a separate bug report.