Dim files when you 'cut' them for later 'paste' action

Reported by Fred on 2008-02-22
124
This bug affects 19 people
Affects Status Importance Assigned to Milestone
Nautilus
Fix Released
Wishlist
One Hundred Papercuts
Medium
Unassigned
nautilus (Ubuntu)
Wishlist
Ubuntu Desktop Bugs

Bug Description

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"

GNOME 2.21.91
nautilus 1:2.21.91-0ubuntu3

So I right-clicked on a file and selected "Cut" in the context menu.
So that I later could "Paste" the file into another directory.

Make so that when you select "Cut" on a file, the icon becomes dimmed.
Because right now, there are no visual indication, so you don't know it worked.
In Windows there is a visual notification by the icon becoming dimmed.
In Ubuntu there is no visual notification, the icon does not become dimmed. This is confusing.

Related branches

Sebastien Bacher (seb128) wrote :

Thank you for your bug report. That's alright known upstream, you can read about it on http://bugzilla.gnome.org/show_bug.cgi?id=47948

Changed in nautilus:
assignee: nobody → desktop-bugs
status: New → Triaged
Fred (eldmannen+launchpad) wrote :

Thanks, I did not know.

But this has been known on GNOME bugzilla since 2001-03-30.
That is 7 years, they're hopeless. They never fix it. :(

Changed in nautilus:
status: Unknown → Confirmed
manzur (sl-solaris) wrote :

2009 this hasn't been fixed

borrell (borrell) wrote :

I agree, this is a usability issue which is in need of a fix. There is no indication that specific files have been cut from a folder. Upstream do not see this as an important issue but for people switching from Windows it is a major issue as the UI could appear unresponsive as it does not give feedback when a cut operation is performed.

Even if files are not dimmed there needs to be some feedback about the cut operation.

Is there a way something could be implemented through an Ubuntu-specific plugin?

Mat Tomaszewski (mat.t.) wrote :

I do agree this is a needed fix. Very good example of a papercut bug.

Changed in hundredpapercuts:
importance: Undecided → Medium
status: New → Confirmed
billytalent (billytalent) wrote :

Is this change going to be made for release in 10.04. If it is, could you also add a feedback when files are copied.

Kazade (kazade) wrote :

Has anyone recently tried the patch from the Gnome bug?

http://mail.gnome.org/archives/nautilus-list/2005-June/msg00018.html

It likely won't apply cleanly now, but anyone taking on this issue might be able to use it as a starting point.

Ivanka Majic (ivanka) on 2009-06-17
Changed in hundredpapercuts:
status: Confirmed → Triaged
Changed in hundredpapercuts:
assignee: nobody → David Siegel (djsiegel)
status: Triaged → In Progress

Here's a straightforward mockup of dimmed icons.

* Dimming effect is achieved by setting lightness to 100% on icons and/or labels.
* Documents folder has dimmed icon, normal label and emblem.
* Templates folder has dimmed icon and emblem, normal label.
* Ubuntu One folder has dimmed icon, emblem, and label.
* Videos folder has dimmed icon, no emblem, normal label.
* Pictures folder has dimmed icon and label.

I think dimming icon, emblem, label is the most consistent approach. If label lightness cannot be manipulated, we should set the label's status to inactive. Perhaps this dimming effect can be achieved by setting all widgets in the icon container to inactive?

seanh (seanh) wrote :

Dimming the icon is better than nothing but I think the problem goes a little deeper. What do you do if the user copies, rather than cuts, something? Dim that as well? The dimming doesn't seem to make as much sense for copying.

I think this thread: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-June/008724.html> attests to the fact that there is a deeper usability problem with clipboard and cut, copy and paste.

There should be a visualisation (a panel applet, possibly) of the clipboard with the ability to preview its contents. This applet should implement some sort of notification when a cut or copy occurs to show that the content has gone into the clipboard (just like we have an animation when a window is minimised to the panel), and it should be possible to put more than one item in the clipboard. More like the clipboard in Sugar.

Changed in hundredpapercuts:
milestone: none → round-1
Richard Ayotte (rich-ayotte) wrote :

seanh, I really like your ideas. Initially we could simply have a notification that says something like "10 files copied to clipboard" or "10 files cut to clipboard". Later, a compiz animation of the ghost icons that have been cut/copied could fly to a clipboard in the notification area. The copy and cut could also be differentiated with different sounds.

On Mon, Jun 22, 2009 at 04:42:32PM -0000, Richard Ayotte wrote:
> seanh, I really like your ideas. Initially we could simply have a
> notification that says something like "10 files copied to clipboard" or
> "10 files cut to clipboard". Later, a compiz animation of the ghost
> icons that have been cut/copied could fly to a clipboard in the
> notification area. The copy and cut could also be differentiated with
> different sounds.

They're not really my ideas as I'm just saying we should do what Sugar
does. Actually I think an animation of the icons going to the clipboard might
be too much. It would mean icons flying across the screen. The way it
works in Sugar is just that a passive notification, showing the icon for
the content that was cut or copied, pops up next to the clipboard
when something is added. There are different icons for different kinds
of content

I think that's less distracting in two ways: you don't have any
animation flying across the screen, and only a single icon is used for
the notification, no text to read.

Michael Keppler (bananeweizen) wrote :

While some notification or a panel may be a nice addition, neither of them fixes the original problem. If files are cut in Nautilus, the visual indication is needed _exactly there_ because of 2 reasons:
* You may not even see the panel change or notification because it is on the opposite end of your desktop (which may be full of application windows)
* You cannot see _where_ you cut the files if multiple Nautilus windows are open, easily leading to confusion if you switch between the windows.

Sebastien Bacher (seb128) wrote :

the change there is probably not trivial and not really a hundredpapercut change

Changed in hundredpapercuts:
assignee: David Siegel (djsiegel) → nobody
Changed in hundredpapercuts:
assignee: nobody → Cody Russell (bratsche)
Mat Tomaszewski (mat.t.) wrote :

Dimming does not seem like an optimal solution - the icons will look as if they've simply been selected, rather than cut. I think they should become semi-transparent instead.

Moved back so Cody can address next week (and week after).

Changed in hundredpapercuts:
milestone: round-1 → round-3

Mat, please see my mockup and provide feedback if it should be changed. I don't think the items looks selected.

Fred (eldmannen+launchpad) wrote :

I think the mockup looks good.

Chriki™ (chrikitm) wrote :

Another idea could be to add further emblems to the icons of copied/cut files. In the simplest case this could be the stock icons for copy/cut (usually a pair of documents/a pair of scissors). I’ve quickly created another mockup showing this (based on Daniel‘s above – sorry for hijacking the screenshot …).

Probably some design person will find ways to further improve this idea, e.g., by adding some striking background color to the little emblem. Unfortunately I have no idea how easy this would be to implement … maybe the existing emblem infrastructure could be used for this?

Chriki™ (chrikitm) wrote :

Sorry for the mistake in my previous post: I meant David’s mockup, of course, when writing about the base of my new mockup …

Cody Russell (bratsche) wrote :

I find the cut icons very confusing. They exist on different corners of the icons, and they exist on both dimmed icons and non-dimmed icons.

The only question I have about David's mockup is how prelight/mouseover affects a dimmed icon. Right now when you mouseover an icon it lightens up a bit, so I guess if you mouseover a dimmed icon then it lightens up some more?

When making these decisions, keep in mind that cut files are not supposed to be there anymore. The dimmed representation is merely a trace of where the file used to be, not the file itself. I recommend we do not have a mouseover effect for cut file representations.

Simone Di Somma (destino26) wrote :

I love the scissor idea, maybe it could be used in combination with the dimmed effect. I think the mouseover effect is necessary because you can open the file, move it around, until you paste the file in another place and least but not last you could simple change idea.

manzur (sl-solaris) wrote :

I do not love the scissor idea, diming files is a good idea to begin, I think everyone agree with it, but the sissor idea is very heavy for me and i do not really like it, simpler things are better...

manzur wrote:
> I do not love the scissor idea, diming files is a good idea to begin, I
> think everyone agree with it, but the sissor idea is very heavy for me
> and i do not really like it, simpler things are better...
>
>
I'd recommend making the files semi-transparent, dimming would suggest
they're merely selected, not "about to disappear from here".

Mat

Chriki™ (chrikitm) wrote :

Cody Russel wrote:
> I find the cut icons very confusing. They exist on different corners of
> the icons, and they exist on both dimmed icons and non-dimmed
> icons.

Sorry about that. As said, I had just taken David’s mockup. The small emblems are on different corners to try out different possibilities.

manzur wrote:
> I do not love the scissor idea, diming files is a good idea to begin, I
> think everyone agree with it, but the sissor idea is very heavy for me
> and i do not really like it, simpler things are better...

As mentioned, I’m not an artist. My mockup should just show the general idea which could be fleshed out by a good artist. Of course the emblems could be grayed out (unless moving your mouse over the icon, maybe?) or completely different – as long as the user is still able to recognize them. Taking the stock icons for copy/cut was just the quickest solution ;-)

There is one advantage about my idea that I perhaps failed to make clear enough in my original comment: with different emblems the idea provides for both cut and copy actions (which is not shown in my mockup). Also, there are probably already provisions in Nautilus for handling such emblems; at least there are the default Nautilus emblems which should work similarly.

Cody Russell (bratsche) wrote :

"There is one advantage about my idea that I perhaps failed to make clear enough in my original comment: with different emblems the idea provides for both cut and copy actions (which is not shown in my mockup). Also, there are probably already provisions in Nautilus for handling such emblems; at least there are the default Nautilus emblems which should work similarly."

I like that there's an interest in going this direction, but for me I think emblems is not the right approach. There was some talk by Nautilus people before about having a 'shelf' system (which is kind of akin to the 'trash' system in a way) wherein you shelve items that have been copied or cut, and at some point you can view them in the shelf. Conceptually this makes much more sense to me because cut/copied items will always be in the same place, and to find out what "Paste" will yield at any given time is as simple as looking in your shelf.

I think dimming an icon that represents a cut icon is important because it indicates, as David said, that this file may soon cease to exist in its present location. I don't think there's really a need to give any indication at all of a copied file in its existing location. When you copy a file, that doesn't affect the file in its original location and it's really only useful to know about copied files when you're in a different location.

That said, while I like the shelf idea conceptually.. I also don't have any brilliant ideas about how that might work in terms of a user interface/experience. If someone here comes up with something brilliant, you'll be a hero to many.

Vish (vish) wrote :

I really like Chriki™'s idea , of using the scissors, and the copy emblem. its a nice touch

@Chriki™ : Pls do a better mockup[for cut and for copy], and post it here, it is nice idea, and it would be a shame to scarp the idea , just because people didnt get the idea properly.

Vish (vish) wrote :

@Chriki™: oh.. another suggestion ,the cut files need to be dimmed since they will be moved but the copy files dont have to be dimmed, but just have a copy emblem

Has this idea, perhaps, stagnated?

Replacing this paper cut within its milestone because it has stagnated.

Changed in hundredpapercuts:
milestone: round-3 → none
status: In Progress → Confirmed
Cody Russell (bratsche) on 2010-03-11
Changed in hundredpapercuts:
assignee: Cody Russell (bratsche) → nobody

Removing from paper cuts. Cody has shown that this is not trivial (it's a feature).

Changed in hundredpapercuts:
status: Confirmed → Invalid
Fred (eldmannen+launchpad) wrote :

Two years later and we're at Ubuntu 10.04 and this is still an usability issue.

tags: added: cut paste usability
tags: removed: cut paste usability
Changed in nautilus:
status: Confirmed → In Progress
Changed in nautilus:
status: In Progress → Fix Released
Vish (vish) wrote :

This has now been fixed upstream and will be available in the next Ubuntu release.

Changed in nautilus (Ubuntu):
status: Triaged → Fix Committed
manzur (sl-solaris) wrote :

Can it be fixed for ubuntu 10.04.1 release?

Sebastien Bacher (seb128) wrote :

> Can it be fixed for ubuntu 10.04.1 release?

No, it's a new feature and quite some new code and doesn't apply easily to the lucid version

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nautilus - 1:2.31.6-0ubuntu1

---------------
nautilus (1:2.31.6-0ubuntu1) maverick; urgency=low

  * New upstream version:
    - This release is based on 2.30.1
    - Expand and collapse folders with +/- in list view
    - Rename .desktop files also change their name on disk
    - Support overriding .gnome2 directory
    - Save passwords for the session by default
    - Remove deleted folders from the pathbar (lp: #19069)
    - Replace libunique with GApplication
    - Don't show 'File Browser' anymore in the window title
    - Port to GDBus
    - Change the default order for files in special directories (lp: #404150)
    - Support relative paths in the location entry/dialog.
    - Use folder icons as window icons in browser and spatial mode (lp: #43608)
    - Add 'Trashed On' and 'Original Location' columns in the trash
      (lp: #301552)
    - Implement transparent icons for cut files (lp: #194213)
    - Change default thumbnail size
    - Fix a number of bugs related to bookmarks (lp: #534043)
    - New dialog to handle conflicts within file copy/move operations
      (lp: #136702, #263338)
    - New button in the trashbar to restore selected items (lp: #553600)
    - Use async I/O to save .gtk-bookmarks
    - Fix a number of issues related to DnD in the places sidebar (lp: #73031)
    - New icon for audio preview
    - Don't show Unmount when showing Eject/Safe Removal
    - Bump libnautilus-extension API version
    - Fix a number of UI glitches
    - Translation updates
    - Eat Control + v to not enable type ahead (lp: #52131)
  * Updated .install files for the gir
  * debian/control.in:
    - build-depends on dh-autoreconf, gobject-introspection and required gir
    - don't use libunique and libdbus-glib
    - list the new gir1.0-nautilus-2.0 binary
    - updated the gtk and glib requirements
  * debian/patches/16_hide_unmount.patch,
    debian/patches/git_browser_title_cleaning.patch,
    debian/patches/git_clean_by_name_rename.patch,
    debian/patches/git_correct_delay_logic.patch,
    debian/patches/git_correct_display_name.patch,
    debian/patches/git_correctly_set_default.patch,
    debian/patches/git_ctrlq_close.patch,
    debian/patches/git_default_thumbnails.patch,
    debian/patches/git_double_click_launcher.patch,
    debian/patches/git_no_double_browse_entry.patch,
    debian/patches/git_store_session_passwords.patch,
    debian/patches/git_typo_fix.patch:
    - the changes are in the new version
  * debian/rules:
    - call dh_girepository
    - use dh-autoreconf
 -- Sebastien Bacher <email address hidden> Thu, 12 Aug 2010 16:41:04 +0200

Changed in nautilus (Ubuntu):
status: Fix Committed → Fix Released
Fred (eldmannen+launchpad) wrote :

I can confirm that this has indeed been fixed in Maverick.
However, I believe the contrast difference is too low.
It is not very noticeable.
The effect is too subtle.

It could be made more obvious/clearer.

Changed in nautilus:
importance: Unknown → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.