Is a file clipboard in nautilus necessary?

Applications
21

That’s how the clipboard mechanism works, whether you like it or not. If you don’t think an application should handle file URIs by pasting them, file an issue with that application. This isn’t magical behaviour, it’s the application doing what it’s been programmed to do.

It’s expected in a GUI file manager, yes. There is zero reason to remove it. Supplement it, sure, but removing the ability to use the clipboard to facilitate file management is entirely unreasonable.

You haven’t proven your replacement is optimal, you’ve only stated that it’s what makes sense to you.

22

Did people abandon GNOME in droves when those features were removed?

23

Convoluted ideas get implemented all the time. Cutting a file in nautilus and pasting it into a text editor doesn’t cut anything. The executed commands don’t reflect the behavior. That’s bad design.

Yes, there is. It’s inconsistent with the behavior in other applications, which makes it confusing.

The Cut and Copy commands in text and image editors make a copy of the selected data and add it to a clipboard. For example, if you cut/copy text in a document, save, close, and delete it, the text can still be pasted into another document. This doesn’t happen with Cut and Copy in nautilus. If you cut/copy a file, move/delete it, and paste it, you’ll get an error or the paste option will be disabled. That’s because a copy of the file wasn’t added to the clipboard, only the pathname was. The Cut and Copy commands in nautilus don’t function the same way they do in other applications. They don’t cut/copy files when issued. They’re inaccurately named. That’s bad design.

The behavior of the Cut command in nautilus is especially confusing because it doesn’t remove the selected files. In other applications, cut removes the selected content, and copy leaves it in place. When files are cut in nautilus and still visible, it’s natural to think a copy was performed because that’s the behavior of a copy command in other applications.

Like I said, one action is simpler than two. And my solution eliminates the inconsistency and ambiguity. Feel free to prove otherwise.

24

I think that keeping the keyboard shortcut but removing the UI option would be a good compromise then.

25

A good short-term solution would be to copy how Apple handles file management in Finder on macOS. Cut would be removed, and an additional modifier key would be used when pasting to move files.

Copy = Ctrl+C = Adds the pathnames of the selected files to the clipboard

Paste = Ctrl+V = Creates copies of the files

Move = Ctrl+Shift+V = Moves the files

The context menu label would change from “Paste (Ctrl+V)” to “Move (Ctrl+Shift+V)” when the Shift key is being held down.

This makes it harder to confuse moving and copying. It eliminates the need for the color-shifting effect that nautilus uses when cutting files. It’s also similar to the way a modifier key is used when dragging and dropping files to differentiate between moving and copying.

The predictable complaints will be, “Oh, great, they’re copying Apple,” but I prefer Apple’s solution over GNOME’s.

26

(oops, double post.)

27

So, having read the discussion, a few things. First, to address this:

You’re assuming it won’t be received positively without any serious testing.

That statement is actually quite simple to prove. Most GNOME users are either former Windows users or Linux users, not former MacOS users. This true simply because of market share. Either way, they are used to “Cut and Paste” in their file browsers. Moreover, most people who end up using Linux, one way or the other, are at least power user enough to know the common file management shortcuts, because you don’t go out of the way to install Linux when you can barely manage files on your OS. Let us say your proposed interim solution gets implemented. What are the immediate effects the average GNOME user feels:

  • Their Cut shorcut suddenly doesn’t work after an update
  • When they find out why their Cut shortcut suddenly doesn’t work, they learn their workflow of Ctrl-X → Ctrl-V got replaced by an objectively clunkier workflow of Ctrl-C → Ctrl+Shift/Command+V, since they now also have to use an extra finger to press one other button or press Shift+Ctrl with one finger on the second command

That is, their workflow simply becomes a whole lot worse for no reason and another reason to hate GNOME is born.

The context menu label would change from “Paste (Ctrl+V)” to “Move (Ctrl+Shift+V)” when the Shift key is being held down

How is this discoverable? Shortcuts should be:

  1. Consistent
  2. Discoverable, if not consistent

Pretty much no other app uses Ctrl+Shift+V to move something or, like, uses Ctrl+Shift+V at all. So consistency is right out of the window. For discovery, it should be obvious what you can do to files right from the context menu and no other context menu changes when you hold shift, so that is not discoverable.

This makes it harder to confuse moving and copying

You need to substantiate the argument that there are, in fact, people in this world who commonly confuse moving and copying.

Again, I will have to agree with the app author and say that most of your arguments boil down to “I don’t do that, I don’t like that, therefore thing should change.” It is evident that your file management needs are different than those of other people. You don’t nest hierarchies, other people may nest them a lot more. You don’t often move files between full screen windows, other people do.

Another advantage of “a file clipboard” for file management that you don’t consider is the fact that it is delayed. You can cut a file, do whatever it is you need to do in the other window, then move the file through Ctrl-V. This is a thing people do on, well, every system, but this is doubly important in Nautilus given that the file picker is really not that great to work in.

Finally, another thing I noticed is that you reference MacOS, iPadOS and also mobile OS sharing functionality. There are two things here:

  1. The needs for file management on mobile and desktop are different. Despite mobile OSes including minimal multitasking functionality, they are still meant primarily for single app operation. This is precisely why most apps include some sort of file management functionality instead of relying on the OS.
  2. This, by the way, runs in contrast with how GNOME does it. Why do the apps need to manage files if GNOME can do it for them? This is how most GNOME apps work by the way, they have minimal file management functions and expect you too use your file manager/file picker.
  3. The underlying assumption here is that Apple delivers a good end user experience with MacOS and iPadOS. Particularly considering MacOS, this may be true for a certain percentage of their users, but it is extremely far from true for all of their users, as evidenced by a huge ecosystem of extensions that modify how MacOS works, countless Reddit threads on “How do I cut and paste files on Finder”, and tips and tweaks videos on Youtube from seasoned Mac users with “top 25 tips to make MacOS usable”. GNOME can do better than Apple.

As an aside, it is impossible to calculate how many people left GNOME after whichever change. Firstly, because Linux does not really do telemetry. Secondly, GNOME is highly extensible and many changes can be reverted through either extensions or config tweaks, which are commonly done by distros by default, so many distros simply won’t notice that a change even made it in. But yes, while many things GNOME has done “for the greater good” have been received extremely negatively by the online communities and, for what it is worth, GNOME got forked more times than any other DE.

There is no need to add further kindling to the fire. GNOME changing workspace orientation from vertical to horizontal may be annoying to desktop users because now mouse scroll doesn’t match virtual desktop orientation, but it is a very slight visual annoyance at best (and even that generated an extension). Removing minimize and maximize by default may be odd, but that is tweaked through gsettings easily enough. However, Nautilus removing the file clipboard or even removing just the Cut’n’Paste functionality and replacing it with Copy and Move in an update wouldn’t be something well-received at all. It would, in fact, be something worth switching DEs over.

28

Okay, here’s an idea I’m working on:

Move/Copy modes:

  1. User selects files
  2. User issues Move/Copy command
  3. Nautilus switches to a Move/Copy mode
  4. User navigates to a different directory or switches to a different tab/window
  5. A button appears that says “Move/Copy here”
  6. User hits Enter or clicks button to move/copy files
  7. Nautilus exits Move/Copy mode
  8. Destination directory stays open

This would avoid the need to open a dialog box. It eliminates the ambiguity. And it’s one continuous action. It also doesn’t require mouse/trackpad input.

Edit: I have some concerns, but I’d like to hear what other people think about this idea.

29

Take a look at my suggestion for Move/Copy modes. They don’t require a dialog box to open. And they’re simpler than cut/copy+paste.

30

After thinking over my Move/Copy modes, the big problem I see is speed. A native directory box would be faster. Tab/window switching and DND are slow. Open directory views aren’t optimized for quickly selecting a destination.

A native directory box would need to be created and optimized for speed. There should be an expanded list of recently accessed directories, including currently open tabs. Bookmarks would also be shown. This would be similar to the way web browsers suggest bookmarks, history, and open tabs when using the search bar. This would eliminate redundant navigation. The search bar in the directory box would have the focus by default. If a user starts typing, bookmarks, recently used directories, and open tabs would be suggested.

Both of these modal solutions are better than the current design. Familiarity bias is holding GNOME back.

31

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.