GNOME Bugzilla – Bug 573915
Use a progress window instead of a notification for cache flushing
Last modified: 2010-01-19 23:15:58 UTC
Hello! gnome-mount currently uses a notification with an indefinite timeout (i. e. infinite, and the notification is manually removed). This is supported by the standard GNOME notification-daemon, but e. g. not by notify-osd [1] which we use in Ubuntu now. Thus Matthew Paul Thomas sketched an alternative implementation which uses an alert window with a progress bar: https://wiki.ubuntu.com/NotifyOSD#gnome-mount I did a first cut at the implementation, see those screenshots: http://launchpadlibrarian.net/23359790/cache-flushing.png http://launchpadlibrarian.net/23359790/cache-flushing.png It's not perfect yet, but before I go on, I'd like to get your opinion: Do you consider adopting this approach at all? If you prefer the progress bar window, I'll clean the patch to rip out all the libnotify stuff (since it isn't used any more), then it'll get bigger, but is cleaner for upstream adoption. If you prefer to continue to use libnotify in the upstream version, please close this bug, and I'll discuss that again with Matthew. Matthew's spec also simplifies the strings (see bug #570499), but for now I didn't do that yet, since that should really happen in accordance with upstream; distro specific string changes are a pain. Thank you in advance for any comment, Martin [1] https://launchpad.net/notify-osd
Created attachment 129936 [details] [review] replace flush notifications with alert window
Whoops, the second screenshot was supposed to be http://launchpadlibrarian.net/23359803/flushing-done.png
Hey, I'm not opposed to using an alert window instead. I am, however, a bit puzzled by the progress bar in http://launchpadlibrarian.net/23359790/cache-flushing.png I mean, there's no good way of knowing how long a write will take, the kernel, AFAIK, just doesn't expose this information. So we can't really use a progress bar. Anyway, for GNOME 2.28, GVfs will use the DeviceKit-disks/gnome-disk-utility volume monitor which doesn't use gnome-mount (bug 573826 has the patch). So gnome-mount is pretty much going away. Since gnome-mount is going away, the question is from where we are going display such alerts. The last few paragraphs of this mail http://mail.gnome.org/archives/gvfs-list/2009-February/msg00012.html has some speculation about that. So we'll probably do a Nautilus extension or gnome-settings-daemon plug-in for this. I expect this code will live in the gnome-disk-utility git repo. http://git.gnome.org/cgit/gnome-disk-utility/ Btw, there's also other dialogs / alerts we want to display (SMART status indicates that a disk is failing, RAID array is degraded etc. etc.) so it would be helpful to factor that into the design before anyone starts writing any code. I don't yet have a bugzilla product for g-d-u (that's bug 573995) but when there is one, we should probably move this bug over.
progress bar> that's just an indefinite pulsating one; the screenshot doesn't make that clear, sorry. Indeed there is currently on way to predict how long flushing will take for a particular device. (There are "dirty" cache stats, but they are for the entire system). I'm happy to replace the progress bar with something else, but it seems that the current GTK way is to use a pulsating progress bar; or does GTK have another throbber which would be more adequate here? Thanks for the heads-up about gnome-mount's future! My _real_ preference would be to make all this "cache flush in progress" entirely obsolete and get the kernel's "flush" mount option to actually work on VFAT (as it is supposed to be for several kernel releases already), and preferably also on ntfs-3g and ext[34]. Once we have those, we could safely drop all this UI mess, and present disk operations in GNOME as they should be (copy progress bars, file save dialogs, etc. stay around until the file is completely written). However, fixing the kernel side is way out of my skills, I'm afraid :(
Just to clarify why the window contains a progress bar, it's because it's a progress window <http://library.gnome.org/devel/hig-book/stable/windows-progress.html.en>, not an alert. It's a subtle design point, but giving a progress window a progress bar -- even if it's indeterminate the whole time, as in this case -- helps people instantly distinguish the window from an alert or dialog and thereby avoids misleading them into trying to dismiss it.
gnome-mount is dead, so closing this.