After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 775891 - Improve the presentation of unmount notifications
Improve the presentation of unmount notifications
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: general
3.22.x
Other Linux
: Normal normal
: 3.24
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-12-09 16:14 UTC by Allan Day
Modified: 2017-03-27 18:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
udisks2: Improve unmount notifications (1.81 KB, patch)
2016-12-22 15:47 UTC, Ondrej Holy
committed Details | Review
udisks2: Refactor notification handling (5.61 KB, patch)
2016-12-22 15:48 UTC, Ondrej Holy
committed Details | Review
window: Use symbolic icon for notifications (1.01 KB, patch)
2017-03-13 12:16 UTC, Carlos Soriano
none Details | Review

Description Allan Day 2016-12-09 16:14:34 UTC
The unmount notifications, that read "You can now unplug <drive>" could look and read better.

 * Since they are system notifications, it would be better if they used a symbolic icon
 * Strings generally shouldn't address the user directly. Instead of "You can now...", it would be better to say "<drive> can be safely unplugged"
 * Notifications should always have a description. In this case, something like "Device can be removed." would work, and might help in situations where "unplugged" isn't quite the right word to use.
Comment 1 Ondrej Holy 2016-12-15 12:16:21 UTC
The string comes from GVfs. I will prepare patch changing the strings (the symbolic icon should be added by Nautilus). However, there are more strings which can be printed, when unmounting:

Notifications, which can be shown when ejecting/stopping drive:
- "Writing data to %s\nDon’t unplug until finished"
- "You can now unplug %s\n" ---> "% can be safely unplugged\nDevice can be removed."

Notifications, which are shown in other cases (for mounts without drives, or if ejecting/stopping is not supported for some reason):
- "Unmounting %s\nPlease wait"
- "%s has been unmounted\n"

Allan, can you please check rest of the notifications also?
Comment 2 Allan Day 2016-12-16 15:38:32 UTC
OK, here's my attempt at rewriting each of those notifications! 

1.

Writing data to <device>
Device should not be unplugged.

2.

<device> can be safely unplugged
Device can be removed.

3.

Unmounting <device>
Please wait to unplug device.

4.

<device> unmounted
Device can be safely unplugged.
Comment 3 Ondrej Holy 2016-12-19 11:59:46 UTC
Thanks! The 1. and 2. looks good, but I am not really sure with 3. and 4. Sorry that I haven't described it with more details initially.

The problem is that the drive can have multiple volumes/mounts. The 3. and 4. are shown also if you unmount just one of the mounts, so other volumes may be still mounted and it is not safe to unplug the drive (see Bug 774192). So we should not talk about unplugging...

Another problem is that it can be shown also when unmounting volume without drive (e.g. whatever from fstab like cifs mount, nfs mount, mounted iso...), so we should not talk about device, because it doesn't have to be actually a device...

Do you have any idea what we can do with it?
Comment 4 Allan Day 2016-12-20 12:54:17 UTC
(In reply to Ondrej Holy from comment #3)
...
> Do you have any idea what we can do with it?

Something like this, perhaps?

3.

Unmounting <filesystem>
Disconnecting from filesystem.

4.

<device> unmounted
Filesystem has been disconnected.
Comment 5 Ondrej Holy 2016-12-22 15:47:50 UTC
Created attachment 342391 [details] [review]
udisks2: Improve unmount notifications

Do not address the user directly in the strings. Add a missing
description for the notifications.
Comment 6 Ondrej Holy 2016-12-22 15:48:11 UTC
Created attachment 342392 [details] [review]
udisks2: Refactor notification handling

The generic_text variable is used currently to determine which strings
should be used for notifications. It is TRUE if unmounting (i.e. mount
is set) and FALSE otherwise (i.e. drive is set). Remove this variable
and make it more obvious...
Comment 7 Ondrej Holy 2016-12-22 15:49:47 UTC
Allan, thanks, that looks good. So I've provided patches for GVfs, rest should be improved on Nautilus side...
Comment 8 Ondrej Holy 2017-01-11 08:37:51 UTC
Attachment 342391 [details] pushed as f834b3a - udisks2: Improve unmount notifications
Attachment 342392 [details] pushed as c6a3c83 - udisks2: Refactor notification handling
Comment 9 Allan Day 2017-03-09 19:13:09 UTC
Is this fixed?
Comment 10 Ondrej Holy 2017-03-10 07:06:12 UTC
(In reply to Allan Day from comment #0)
> The unmount notifications, that read "You can now unplug <drive>" could look
> and read better.
> 
>  * Since they are system notifications, it would be better if they used a
> symbolic icon

missing

>  * Strings generally shouldn't address the user directly. Instead of "You
> can now...", it would be better to say "<drive> can be safely unplugged"

done

>  * Notifications should always have a description. In this case, something
> like "Device can be removed." would work, and might help in situations where
> "unplugged" isn't quite the right word to use.

done
Comment 11 Ondrej Holy 2017-03-13 11:15:32 UTC
Hmm, I've seen a symbolic icon on rawhide, so it is probably fixed... Carlos, don't you know?
Comment 12 Carlos Soriano 2017-03-13 12:15:50 UTC
It was changed in gnome-shell https://git.gnome.org/browse/gnome-shell/commit/?id=d3c050b88d497e87eb54bb3787a122cd282a89f6

Not sure is the app who should say to use a symbolic icon for the notification, but why not, patch upcoming.
Comment 13 Carlos Soriano 2017-03-13 12:16:05 UTC
Created attachment 347830 [details] [review]
window: Use symbolic icon for notifications

We prefer symbolic icons, even though gnome-shell now uses symbolic
icons anyway for notifications if it's available.
Comment 15 Allan Day 2017-03-27 18:32:46 UTC
Thanks!