unity-design team mailing list archive

[Gregory Merchan <gregory.merchan@xxxxxxxxx>]

On Wed, Sep 19, 2012 at 2:07 PM, Dylan McCall <dylanmccall@xxxxxxxxx> wrote:
> This is all intended behaviour. A lot of it is explained in the wiki,
> at https://wiki.ubuntu.com/NotifyOSD and
> https://wiki.ubuntu.com/NotificationDesignGuidelines. You can find the
> rationale, as well as some advice on how to do pretty well any kind of
> notification.

I figured it was so. I was in a bit of a rush that morning.


> On Wed, Sep 19, 2012 at 10:52 AM, Gregory Merchan
> . . .
>> 1) The notifications should have come within about 2 seconds of each
>> other, but the time was much longer as each stayed on the screen for a
>> while before it faded and the next one appeared. If I needed to
>> receive some notification in a timely manner, I would not have because
>> of the slowly moving queue.
>
> Normally, you would solve this by updating or appending your existing
> notification. . . .

Ah, I see I was unclear. My intent was not to have notifications every
two seconds, so I don't need to update or append to a notification. I
was observing that although the notify-send messages were two seconds
apart (by accident) the notifications themselves were further apart.
Even looking at the specs now, it seems that what I should have seen,
assuming notify-send doesn't do anything weird, was multiple
notifications on the screen.


> . . . depending on the complexity of
> this program, you might be better off writing it with Python or
> something so you can talk to the libnotify library directly.

It's a simple shell script. It just wgets a number, sees it's high or
low, notify-sends if it's low. I just happened to be debugging when I
gave the wrong `watch` time, so I was showing myself the number every
time.


>> 2) I knew there were a bunch of notifications queued and I couldn't do
>> anything about it. I couldn't dismiss the notices, see the queue,
>> dismiss the queue, or anything. I had to wait and wait for all the
>> messages to go through.
>
> There are a few things here:
>
> Applications should not be blasting you with notifications. . . .
> . . . With that solved, there should be no need for a queue . . .

Of course applications shouldn't be doing that, but what's my fail-safe?

There is a queue, even if there's no visual representation of it; it's
the queue of pending notifications. This is unavoidable, unless
visually overlapping notifications are OK. In this case I know why I'm
seeing notifications come and go one after the other; it's because I
screwed up. But imagine the frustration of a user who has installed a
buggy application and is being bombarded. There's no apparent way to
turn them off. The user may not even know which is the offending
application.

>From the spec, the guy at the help desk should be able to check
~/.cache/notify-osd.log to sort out the problem, but that's not
working here. It looks like it hasn't worked since April, and I can
tell that because it the file hasn't been removed as it should have
been.

The only usable option I can suss out is to monitor dbus.

> Meanwhile, applications that want to provide urgent information will
> find some trouble here, and that is intentional. If notifications
> aren't working as you want them, it's a hint that you are better off
> notifying the user in some other way. That's where the Notification
> Design Guidelines wiki page is very helpful. If your notification is
> more important than any other notification, it isn't a notification:
> it's an alert. You can create an alert box using Zenity, and it will
> appear on its own terms ;)
>
> I hope that helps!

I must say it bothers me that more people don't notice when they have
a machine in front of them that can monitor anything it can get a
signal from, process that signal, and respond to it. But I also see
that it's harder to do that than it could be.