If it ever builds…
In notify-osd trunk are things I’d like people under Karmic to get their hands on. Namely:
- proximity-based fade-on-hover
- debug-display bar for notification urgency-levels
- corrected under- and overshoot behaviour of value-indicator
What you’ll get will look like this screencast. Due to the changes to the value-indicator you’ll also have to get new versions of g-s-d and g-p-m.
From my PPA you will need:
- notify-osd 0.9.14
- gnome-settings-daemon - 2.27.3-0ubuntu2~ppa1
- gnome-power-manager - 2.27.1-0ubuntu4~ppa1
If you want to help out with identifying wrongly tagged notifications (in terms of urgency-level) start notify-osd with “DEBUG=1 /usr/lib/notify-osd/notify-osd”. That will give you this debug-bar display at the top. This is meant to gather data for the Do-Not-Disturb mode, where we want to filter the display of notifications based on their urgency-level and the state of the system (e.g. screensaver on, doing a presentation, watching movie). So if you run notify-osd with that thing on and then for example see a “Battery low” notification with low urgency, file a bug against the application which triggered this (hint: look in your ~/.cache/notify-osd.log). Thanks in advance!
June 20th, 2009 at 10:03 pm
I don’t like the proximity current behavior. I would prefer that the fade does not depend on how much is the pointer near the notify, but simply when the pointer enters the area, there is a fade which lasts in 300ms.
This is my opinion, thanks
June 21st, 2009 at 10:21 am
On a completely unrelated issue: Are you aware that notify-osd doesn\’t drop events if it\’s behind? Pressing dedicated volume keys completely bogs down the system which is especially annoying while watching movies.
June 21st, 2009 at 11:22 am
@ Nicolò: But the cool thing about the proximity-based (not time-based) approach is that no matter how fast you move the mouse, when you’re over the bubble it will be faded and you can fully see through it. If it would be time-based, you could be over the bubble with the pointer and it still wasn’t faded completely. Remember the notifications should never be in the users way. Making the user wait for the UI is a big No-No! The proximity approach is very robust and elegant imo.
@ TrueTom: I know. I also know the reason for this. Also do I know how to fix this. This even on my ToDo. I also started work on the fix. I never wanted to to see this moving unfixed into Jaunty. But I don’t get to choose priorities. “Fate” rather has me spent time on other tasks. Oh, and one last thing… I ignore any bug-reports on my blog
That’s what launchpad.net is for folks.
June 22nd, 2009 at 4:44 pm
@MacSlow: Thanks. I see now this display will not be on by default, but is a debug mode that has to be enabled.
June 22nd, 2009 at 10:58 pm
OT: Great font! What is it?