"Writing data to device" appears as fallback alert

What do you think should the indicator applet do for gnome-mount?

What did gnome-mount previously do when mounting? At the moment, I know the mounted volume shows up in the Places menu, and there is also sometimes a dialog giving options like importing images or auto-running content. I don't think we need a persistent indicator (like network-manager) for auto-mounted volumes.

well besides the menu, and the Desktop, I have the applet (that allows me easily un/mount devices.
AFAICT I see no need for a popup when I disconnect a volume, so a simple indicator would be fine.

About the Mount and a the current dialog, i have no idea. Can/should we keep it?

Which applet is this?

On Tuesday 24 February 2009 20:34:54 Mark Shuttleworth wrote:
> Which applet is this?

Disk Mounter 2.25.91
its available on gnome-applets if i'm not mistaken.
I just added it from the "Add to Panel" wizard.

Ah. That will continue to work in 9.04. It may not work forever, but we
would replace it with something else if that's the case. For the moment,
there are no plans to add a libindicate version of the "mounted disks list".

 status wontfix

Mark

BUGabundo, your bug summary says gmount "popups". What do you mean by that? Can you attach a screenshot of the problem? We've found use of notifications in gmount's code, but haven't been able to persuade it to actually show them in a test environment.

On Wednesday 25 February 2009 10:50:35 Matthew Paul Thomas wrote:
> Can you attach a screenshot of the problem?

On Wednesday 25 February 2009 06:32:30 Mark Shuttleworth wrote:
> For the moment, there are no plans to add a libindicate version of the "mounted disks list".

Mark I'm talking when unmount, not mounting them. The previous email has a screenshot of the message, when I unplug one f my disks, via the mentioned applet.

 status new

--
Hi, I'm BUGabundo, and I am Ubuntu (whyubuntu.com)
(``-_-´´) http://LinuxNoDEI.BUGabundo.net && Ubuntu LoCoTeam Portugal http://ubuntu-pt.org
Linux user #443786 GPG key 1024D/A1784EBB

Ok, that alert needs fixing, not least because it disgracefully asks that you "Please do not remove the media or disconnect the drive" when it knows very well that you already have. (See also bug 325315.) It has nothing to do with libindicate, though.

Just to correct some misunderstandings here: These bubbles appear when you are unmounting a device. If that takes a bit, because the write cache still needs to be written back to it, you first get a notification which says "please do not remove...", and once the cache is flushed and unmounting is complete, you get a new notification "device is now safe to remove".

This is one case where a fixed notification time just doesn't work (I also brought that up very early when I complained about not providing any method of overriding the time).

What do you mean with "proper alert box"? There shouldn't ever be a dialog box which the user has to act on, since the situation will just resolve itself. If the user has to click away two dialog boxes each time he unmounts a device, he will rightfully go crazy..

Ah, I'm sorry I misunderstood. If it's properly warning people not to disconnect/eject, it should be a progress window rather than a notification *or* an alert box.

Hm, why is notify-osd rendering this notification as a dialog box? it's just a simple notification, it doesn't have actions, so there is no "dialog" involved here.

Oh, you are saying notify-osd turns non-default timeouts into dialog boxes? That's wrong, since the dialog boxes won't go automatically the same way than notification bubbles go.

Arguably the usage should be fixed in gnome-mount, but in jaunty it's almost impossible to collect the list of applications which are affected by this (think about third-party apps).

It is gravely wrong to assume that all the software in the world will instantly follow the semantics of notify-osd. This can be done eventually, after a couple of cycles, but not immediately. Even ignoring the timeout is better than converting it into a dialog, but for Jaunty I'm inclined to say that we should respect the timeout, since it's impossible to fix all applications which use timeouts in time.

We queue notifications, they are asynchronous. In other words, it may
not be displayed for some time after the app sent the message. So, we
prefer to display it immediately as an alert, rather than delaying it
then not knowing whether the time relates to reality or not.

Mark

Mark Shuttleworth [2009-02-26 18:47 -0000]:
> So, we prefer to display it immediately as an alert

What does that technically mean, a different kind of notification
bubble (like for brightness), or a message box with no buttons, or
something else?

Thanks, Martin

An alert is a dialog box that has a set of buttons, including OK and
Cancel, and can be dismissed.

Mark

Mark Shuttleworth [2009-02-27 9:12 -0000]:
> An alert is a dialog box that has a set of buttons, including OK and
> Cancel, and can be dismissed.

Hm, but that sounds like the wrong thing to me for this particular
case, since the user isn't supposed to do two additional clicks just
after unmounting?

Should it be an unfocused window with just a bouncing progress bar,
which automatically goes away once umount is done?

FYI *some times* i dont see either (notification or alert), but other times I'm seeing BOTH.

"Hm, why is notify-osd rendering this notification as a dialog box? it's just a simple notification, it doesn't have actions..."

This is not because it has any non-default timeout, and it's not because the notifications are queued. It's almost cerainly because gnome-mount sets expire_timeout to 0, which means that the developer does not want the notification to expire by itself, as all Notify OSD bubbles do. <https://wiki.ubuntu.com/NotifyOSD#org.freedesktop.Notifications.Notify>

So yes, gnome-mount should use a progress window instead, as I said yesterday. I'll provide a mockup of that today. (I'll also add text to the notification design guidelines about not using notification bubbles to show progress; that's never been a good idea, and Notify OSD just makes that more obvious.)

Martin Pitt wrote:
> Should it be an unfocused window with just a bouncing progress bar,
> which automatically goes away once umount is done?
>
Yes!

Matthew Paul Thomas [2009-02-27 12:46 -0000]:
> This is not because it has any non-default timeout, and it's not because
> the notifications are queued. It's almost cerainly because gnome-mount
> sets expire_timeout to 0

Right, that's what I meant. It's used as an _indefinite_ timeout, not
an _infinite_ one.

> ** Changed in: notify-osd
> Status: Confirmed => Invalid

I strongly object to this, though. While we'll see to fix gnome-mount,
we can't possibly fix the entire software world by Jaunty, so at least
for Jaunty itself, notify-osd should respect different timeouts,
including indefinite ones. Otherwise I'm afraid we'll get a lot of bad
press and spoil the story of notify-osd.

Please NB that I am not complaining against disregarding timeouts
_eventually_, just for a transition period (well, I still question
that a fixed 10 second timeout is always the right thing, because I
feel that it's not; but that's a separate issue).

Did you mark this bug as invalid because you insist on disregarding
timeouts for Jaunty, or because it should be tracked in a separate
bug?

Taking for now, unless I find someone else to work on this.

We can't support indefinite timeouts. We have no mechanism to dismiss
them, and they queue up and are displayed serially, so an indefinite
notification would be a real DOS on the system ;-)

I've added a mockup and mini-spec for the progress window. Thanks very much BUGabundo for your help with this.

Martin, if you know of any other programs that use and rely on a specific non-zero expire_timeout, please let me know. Our assumption has been that for any expire_timeout other than zero, it won't matter if Notify OSD decides the duration itself instead.

Matthew, where is that mockup/mini-spec?

Two questions to our design gurus:

 - "Writing data..." alert window: do you prefer an indefinite progress bar, or no progress bar at all? (with current Linux there is no way to predict when the cache flushing will be finished, so we can't have a definite progress bar)

 - The "Device is now safe to remove" event: should that stay a normal notification bubble? Or be integrated in above alert window and disappear automatically after 10 seconds or so?

On Saturday 28 February 2009 13:11:39 Martin Pitt wrote:
> - "Writing data..." alert window: do you prefer an indefinite progress
> bar, or no progress bar at all? (with current Linux there is no way to
> predict when the cache flushing will be finished, so we can't have a
> definite progress bar)

Then dont make it a progress bar, but a cycle around (like bootsplash)

--
Hi, I'm BUGabundo, and I am Ubuntu (whyubuntu.com)
(``-_-´´) http://LinuxNoDEI.BUGabundo.net && Ubuntu LoCoTeam Portugal http://ubuntu-pt.org
Linux user #443786 GPG key 1024D/A1784EBB

Martin, the mockup and mini-spec are linked to in the description of this bug report. As you’ve guessed, they include an indeterminate progress bar, which is replaced by the "safe to remove" text, and the window disappearing a few seconds later.

I have an initial version ready now. It implements the dialog layout and workflow, but continues to use two of the upstream strings:

  Finishing up… -> Writing data to device
  It’s now safe to eject %s-> The device %s is now safe to remove.
  It’s now safe to disconnect %s -> The device %s is now safe to remove.

Changing the strings should really be done in accordance with upstream (see bug 329296), since doing so breaks all translations. The patch introduces one new string ("To prevent data loss, wait until this has finished before disconnecting."), we have to live with that.

Attaching screenshots for both dialogs.

Current patch, which I'll upload in a minute.

This bug was fixed in the package gnome-mount - 0.8-1ubuntu2

---------------
gnome-mount (0.8-1ubuntu2) jaunty; urgency=low

  * Add 09_use_window_for_flushing.patch: Use an alert window for flushing
    instead of notifications. Ubuntu's notify-osd does not support infinite
    timeouts, thus we cannot use notifications. (LP: #332600)

 -- Martin Pitt <email address hidden> Tue, 03 Mar 2009 12:48:16 +0100

The notification window does not show in front of the other windows. It shows always behind the other windows (therefore hidden). In order to see it, I need to click on its corresponding button on the task bar. Is it intentional?

Ricardo Pérez López [2009-04-16 18:59 -0000]:
> The notification window does not show in front of the other windows. It
> shows always behind the other windows (therefore hidden). In order to
> see it, I need to click on its corresponding button on the task bar. Is
> it intentional?

It's not really intentional, it's just the window manager's policy for
new windows, I guess. That's one of the drawbacks that you get for
doing notifications without notifications :-/

Damn. That kind of notification doesn't notify very well, IMHO.

Could it be a way to display the notification window always on top?

Ricardo Pérez López [2009-04-16 21:51 -0000]:
> Could it be a way to display the notification window always on top?

I think there's a WM hint to do that; perhaps you can open a new bug
report and assign it to me?

Sure! I'd just opened the bug #362767. Thanks!

I just ran into this issue with the notifications for media being synced being stupid on my SD card slot.

These things should either be focused and upfront, or special cased like audio/brightness adjustments are in osd-notify so that these (very important, for users of FAT) notifications can _NOT_ be missed.

Remember the fragility of the system most people use on their SD cards, here, guys. And if indef. notifications break notify-osd, then notify-osd is incorrectly designed... the solution would be to support parallel notifications for indefinite things, and serialize the timeout messages (if you absolutely _must_ but that really does work quite horribly on my system).