Is a file clipboard in nautilus necessary?

Applications
#1

Cutting selected content in text and image editors removes it and adds it to a clipboard. In nautilus, cutting files doesn’t remove them. They’re only moved when pasted elsewhere. This behavior is inconsistent and confusing.

This is why Apple doesn’t allow files to be cut in macOS’s Finder or in Files on iOS and iPadOS. I prefer that over Gnome and Windows allowing it.

The reliance on a clipboard makes it easy to accidentally move files when they were intended to be copied. A user could accidentally delete original files believing they were copies.

These problems can be eliminated by getting rid of the file clipboard. Cut/Copy commands would be replaced by the “Move/Copy to…” commands. Paste would be removed. Users would issue a “Move/Copy to…” command and a directory selection box would open instead of adding files to the clipboard. A Duplicate command could also be added to allow a user to duplicate selected files quickly in the same directory.

Is a file clipboard necessary for file management? People use mv, cp, and rm on the command line, not cut, copy, and paste commands that use a clipboard. A file clipboard seems like a mistake.

I think putting files on a clipboard is unnecessary and problematic
#2

Files supports tabs, which I personally use quite often to cut/copy/paste files between directories. The current behavior of move, opening a dialog, does not fit with this workflow.

What I could imagine might make things potentially clearer, is making the “clipboard” more visible in the interface, by having some indicator, much like the current operation progress menu.

#3

The current behavior of move, opening a dialog, does not fit with this workflow.

If needed, a list of open tabs could be added to the directory selection box. (Edit: Ignore this. I forgot there’s a list of recently accessed directories in the directory selection box.)

Bookmarks can also be used to prevent repetitive navigation. Moving files this way would eliminate the constant tab switching you’re doing.

#4

If needed, a list of open tabs could be added to the directory selection box.

That is a lot of hoopla. Moving files within the same interface would be less complicated (besides, the popup is currently not even under the control of Files).

Bookmarks can also be used to prevent repetitive navigation.

Bookmarks are not helpful for temporary one-off navigation.

Moving files this way would eliminate the constant tab switching you’re doing.

It would require re-navigating to these places every time, e.g. on an external hard drive.

#5

That is a lot of hoopla.

True. I’m still working this idea out. I forgot there’s a recent directory list in the directory selection box.

Bookmarks are not helpful for temporary one-off navigation.

I don’t understand what you mean. If you open two tabs for moving/copying, you have to potentially navigate to two locations. If you use one tab and “Move/Copy to…”, you also potentially navigate twice. It’s the same amount of work. If you need to repeatedly move/copy things between these locations, you could use a bookmark or the list of recently accessed directories in the directory selection box.

It would require re-navigating to these places every time, e.g. on an external hard drive.

I don’t understand this either. Why wouldn’t you use a bookmark or recent directory to avoid that? I use bookmarks all the time with “Move/Copy to…”.

#6

I forgot there’s a recent directory list in the directory selection box.

Recent locations somehow always seemed unreliable to me, it often wouldn’t contain a directory I recently worked with. Should probably pay more attention to when that happens.

you also potentially navigate twice.

That is correct. I am thinking of a scenario where you do multiple moves in a row, e.g. collecting scattered files into a predefined structure. Now, yes, you could bookmark that directory while working with it and unbookmark it afterwards, but having tabs open for each location, combined with a file clipboard, does not require navigation for every single operation.

Also, tabs are more forgiving. If a file is moved to the wrong location, it can simply be moved from the tab to its desired location, rather than having to navigate to the incorrectly moved to location.

1 Like
#7

To be clear, I am not saying the current behavior of copy/cutting is a gold standard, but it is very versatile. I think if it were to be streamlined, looking at how to achieve different use cases is very important.

#8

Yeah, I’ve noticed this too, recent files even directories often don’t show up in Nautilus immediately after working on them. Frustrating to no end.

#9

Navigation is a non-issue for me because I don’t deeply nest files, and I use bookmarks.

#10

You have a familiarity bias towards clipboard-based file management, as I did. As soon as I stopped using the clipboard, the benefits of Move/Copy became obvious. It’s inherently simpler, just as mv and cp are simpler than cut/copy/paste would be on the command line. It’s clear to me now that a file clipboard is an unnecessary complication. Using Move/Copy allows me to work faster because it skips the middleman of a clipboard. I only have to think about what files I’m moving/copying and the destination. Move/Copy commands are also easier to implement than a clipboard-based solution.

Early file browser developers assumed a file clipboard was a good idea because text and image editors used clipboards, but they were wrong. The fact that Cut doesn’t remove anything, as it does in other editors, is a dead giveaway that they messed up. File management is fundamentally different than editing arbitrary data.

A developer has said that nautilus will eventually emphasize Move/Copy over using Cut here. In the long run, however, I think file clipboards are going to become obsolete.

#11

Aren’t you ignoring the obvious use case of actually using the clipboard? Nautilus can use the clipboard as input for cut/copy/paste, but the clipboard is its own thing and I don’t see any reason to remove that functionality.

#12

I don’t understand why you’ve come to that conclusion about the Clipboard based on what I said.

I agreed that the “cut” action doesn’t make sense for files in a regular filesystem (because the file is not erased from its current location when cut) and would like to de-emphasize it if the Move to… option ever becomes a superior alternative.

But “cut” is one thing. “Clipboard” is another. The clipboard is essential and a must-have, because it’s a way to copy data between different applications:

  • From GNOME Files to other applications
    • Example: copy image file from GNOME Files, paste it into LibreOffice Impress; this inserts the image into the presentation’s slide.
  • From other applications into GNOME Files.

It wouldn’t make sense for GNOME Files to be the single application which doesn’t support clipboard.

Copy and Paste are here to stay for the foreseeable future.

1 Like
#13

I’m coming to that conclusion based on current trends and my experience. iOS/iPadOS don’t allow cutting in Files. And I think Copy/Paste in that app will get replaced with a Copy command that works similarly to the existing Move command.

That’s not common behavior for average users. I never do that. If I want image or text content from another file, I open it, copy the content, then paste it into the other open file. It makes more sense to transfer content from one open file to another open file rather than transferring a file from a file manager to an open file. Nobody copies a text file in a file manager and pastes it into an open file to transfer the content.

The behavior is also inconsistent. If you copy a text file in nautilus and paste it in the terminal or gedit, the pathname gets pasted, not the content. But if you paste it into LibreOffice Writer, the content gets pasted.

Again, that’s not common behavior. I can’t think of a single time I’ve done that.

Why does any application need a file clipboard? How frequently do average people transfer files that way? Average users use the Send/Share command or Drag and Drop to transfer files to other apps on Apple products. Android also has a Share button. They also use the “Save as…” command to save files to a file manager, which is really just another name for “Copy to…”.

I’d like to hear why people think a file clipboard is needed in Gnome, so I may bring this up in another topic.

#14

This sums up your reasoning.

Still, even if you don’t need it, please just ignore it’s there. I know the context menus are busy and we are working on that. But we are not going to remove features other people use just because you don’t.

#15

And I repeat: I want to de-emphasize and eventually hide the cut option from the menu.

But your hardline reasoning forces me to stand on the other side of the fence. I don’t want the public to assume I agree with such an extremist and user-hostile reasoning.

Then again, my endgame is most likely going to be pretty close to what you want. But I believe we can get there without alienating everyone.

2 Likes
#16

I think you’re being a little provincial about what an average user does or should do. This is exactly how I perform these tasks and have for decades.

The owner of the current clipboard selection offers a list of formats it can transfer the data in, and the receiving application requests the format appropriate for what it intends to do with it.

File managers operate on files, so that’s how they use the clipboard content. Word processors compose documents, often from elements that are files like images. If you think the clipboard usage of gedit is incorrect, you should open an issue recommending it attempt to open or insert the content from text files.

My experience disagrees again. I do this fairly frequently.

There is no such thing as a “file clipboard”, which seems to be something you’re misunderstanding. The “clipboard” is a method for transferring data between applications, and there aren’t different clipboards for each type of content.

Because copying and moving files is one of the most common operations users perform in file managers, and using the clipboard as a mechanism to do it has been the established user experience for decades.

#17

No, it doesn’t. You’re distorting my argument.

I want it removed because Cut/Copy and Paste are two distinct actions. Move/Copy are single actions. Bypassing a clipboard is objectively simpler.

Conceptually:

Move/Copy = A → B

Cut/Copy + Paste = A → C, C → B

By having redundant ways to do something, you’re increasing the cognitive load on the user and slowing them down.

I also want it removed because cutting in nautilus is inconsistent with cutting content in other applications, which makes it confusing. When a user cuts files in nautilus and sees they’re still there, the natural reaction is to assume a copy was performed because that’s the behavior of a copy. The color-shifting effect doesn’t eliminate the ambiguity.

A file manager should be dead simple. Moving files is their primary purpose, and there shouldn’t be any ambiguity when doing so, as there is now.

#18

That doesn’t matter. The expected result of cutting/copying+pasting a file is the creation of a file and possibly the removal of the original. It’s not intuitive to have the pathname or the contents of the file pasted. It’s convoluted design. It’s “gee-whiz” or “magical” behavior.

By “file clipboard” I mean a clipboard that’s used for file management. To clarify, I’m asking “Is a clipboard necessary for file management?”

That doesn’t mean it’s optimal. A move is one continuous action. Cut and Paste are two distinct actions. One action is objectively simpler than two. That’s why we use mv on the command line, not cut and paste.

There’s also no ambiguity when moving files as there is when cutting and pasting. That’s why there’s no “Cut” command in Apple’s Files app on iOS/iPadOS.

#19

You’re assuming it won’t be received positively without any serious testing. If you make an improvement, the benefits should be obvious, and a lot of people will embrace it. If you don’t make an improvement, you’ll discard the idea. In either case, there’s nothing to worry about. Complaints based on familiarity bias aren’t meaningful.

People have already become accustomed to not using Cut for file management on Apple devices.

Another thing to consider is the decrease in reliance on dedicated file managers in general. A lot of applications now have document management built-in, like Apple’s Notes app. Apple doesn’t want people managing local Notes files with a file manager. People who grow up on iPhones/iPads are going to be confused by the idea of cutting files. And streaming apps don’t require any local file management. Cut+Paste doesn’t seem complicated to you because you likely grew up with it and applications that didn’t have built-in document management.

#20

I wish that was true. 10 years following this project has show me that’s never the case when something is removed, even if it is for an overall improvement.