On Wed, Sep 19, 2012 at 2:07 PM, Dylan McCall <dylanmcc...@gmail.com> 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. -- Mailing list: https://launchpad.net/~unity-design Post to : unity-design@lists.launchpad.net Unsubscribe : https://launchpad.net/~unity-design More help : https://help.launchpad.net/ListHelp
