GNOME Bugzilla – Bug 679335
Add an easy shortcut to move files between open nautilus windows
Last modified: 2021-06-18 15:48:46 UTC
The removal of the extra pane feature broke an important use-case of nautilus for me. I often used the extra pane to organise between two locations without copy/past or drag+drop. My workflow was 0. open 2 panes, one source, one dest. 1. select items in source, often a large non-contiguous set 2. right click -> move to -> other pane How about bringing back a similar feature 0. nautilus has a few windows open at different locations 1. select items in one nautilus window, often a large non-contiguous set 2. right click -> move to submenu -> list of locations that *other* nautilus windows are currently showing.
Sounds like a nice way to preserve most of the split pane benefits, indeed
There are a couple of issues with the proposal: * You have to plan in advance by opening the correct location * You have to keep the location open in a Nautilus window * It requires that Move To... becomes a sub-menu rather than being a single menu item Bug 679298 largely avoids these issues, since it allows you to select the objects you want to move/copy and then decide where to put them - this is definitely the more natural sequence in which to do things. However, perhaps the workflow suggested by John could be supported. With bug 679298, it would just require that the File Chooser updates its Recent list based on locations viewed in Nautilus, if I'm understanding correctly...
(In reply to comment #2) > There are a couple of issues with the proposal: > > * You have to plan in advance by opening the correct location > * You have to keep the location open in a Nautilus window > * It requires that Move To... becomes a sub-menu rather than being a single > menu item > > Bug 679298 largely avoids these issues, since it allows you to select the > objects you want to move/copy and then decide where to put them - this is > definitely the more natural sequence in which to do things. I disagree with your assertion that this is unnatural. Or I don't understand it. Can you please clarify?
I should expand on this I guess. File management, or as my use-case goes, file organization is a proactive exercise. I open various nautilus windows to a bunch of destinations, I consider the files in the source, and then I decide to move groups of source files to the destinations based on their content. I don't see how this is different to opening multiple text documents, and moving content between them via copy and paste. Except this is slightly less clicking. I repeat. This is to restore an important case of file management and reorganization, not ad-hoc movement of a single file.
(In reply to comment #3) ... > I disagree with your assertion that this is unnatural. Or I don't understand > it. > > Can you please clarify? It is a common principle in interaction design to allow people to make decisions as a part of situated action, rather than in a planned manner [1]. You pick something up, then you decide where to put it. Even if you have a pre-existing idea of where it should go, you might alter your behaviour based on what you encounter on the way. You might encounter a file that you forgot about, for example, and decide to change the destination for the move operation. Generally speaking, facilitating this context-driven mode of action, rather than requiring people to specifically plan their actions before they make them, is seen as providing a better experience. Not only does it accord with the most popular ways of operating, but it is also less fragile and error-prone. That's what I meant by unnatural. To reiterate - I think it would be good to support the workflow that you've described, but I'd prefer to do so within the move/copy to work in bug 679298, rather than adding a new menu item for it.
> > To reiterate - I think it would be good to support the workflow that you've > described, but I'd prefer to do so within the move/copy to work in bug > 679298, rather than adding a new menu item for it. We had a (sub)menu 7 days ago! I still think the removal of this feature penalizes those people who do specifically plan and organize their actions - like myself when organizing files. If you accept this point, then I don't see the motivation of going through this modal sequence of operations (selecting recent location in the file chooser). Is it to stop the proliferation of sub-menus, to funnel people through the same set of steps for consistency, or some other reason? I also think polluting recent files with every location browsed in nautilus, as am implementation detail, is messy. Oh, and you forgot ref [1] - I will take a look. p.s. I usually have one task per desktop. On each desktop I usually have an editor, a terminal, a nautilus window, etc. Its very much activity based. If I go into my downloads folder I move things to the storage location related to the task (which will be associated with a desktop and have a nautilus window open). The typical things that I move are 1. PDFs (papers, etc). 2. Simulation results. 3. experimental results. Some of 2/3 go into an archive, that which are noteworthy get moved to a working directory for further analysis. In our lab I see a similar file management scheme for the others doing experiments.
(In reply to comment #6) ... Let's shift tack a little bit - how do you propose that we reconcile your proposal with bug 679298? > Oh, and you forgot ref [1] - I will take a look. ... Ah, sorry! It's a classic - and foundational - book on HCI. Good fun if you're into the history of these things. It's coming from a good place theoretically, too. [1] http://www.amazon.com/Plans-Situated-Actions-Human-Machine-Communication/dp/0521337399
(In reply to comment #7) > (In reply to comment #6) > ... > > Let's shift tack a little bit - how do you propose that we reconcile your > proposal with bug 679298? Restore Move To and Copy to back to the submenus they were Right click -> Move to -> [Select location... ] |-------------------| |# Downloads | |# Drosophila data | |# Bundle Adjustment| |-------------------| Copy to is the same structure The names are the last fragment of the path in each nautilus window. The # is the icon associated with the path. If the path is well known (Downloads, Music, etc) it gets that icon. Otherwise it gets the normal folder icon. It might also be useful to indicate if the path is remote by showing a network folder icon instead of the normal one. Only expose the 'select location' form/action of Copy to and Move to in the application/window menu (don't expose the list of folders there). > > > Oh, and you forgot ref [1] - I will take a look. ... > > Ah, sorry! It's a classic - and foundational - book on HCI. Good fun if you're > into the history of these things. It's coming from a good place theoretically, > too. > > [1] > http://www.amazon.com/Plans-Situated-Actions-Human-Machine-Communication/dp/0521337399
Oh, Select location... brings up the file chooser as recently implmented, in case it was not clear.
And what if you don't have any other Nautilus windows open?
(In reply to comment #10) > And what if you don't have any other Nautilus windows open? For the context menu, either 1. hide the separator and just show "Select Location..." as the only option in the submenu 2. remove the submenu and just show "Move to Location" and "Copy to Location" as the only option in the right click menu. If you don't like dynamically changing menus then go with an approach inspired by Open / Open With model and the new-style wireframes on github. right click -> [bla ] |----------------| |Move to... |Move to window >| |----------------| [bla ] The 'Move to window' submenu is the list as proposed earlier. Drop the Move to window (or make it insensitive if no other Nautilus windows are open).
please please please link bugs if discussion is continued elsewhere (bug 679580)
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.