Desktop notification
Really, I don't get this. The GNOME guys started the libnotify integration (once again?), which lead to controversial discussion. I wonder why thinks have to be that complicated all the time. Why not simply design a desktop notification system based on the ideas used in system notification - namely syslog. Speaking from the flexibility's point-of-view. You have different, pre-defined levels of importance. And you have various services, like Thunderbird or the battery monitor, that want to present notifications. Now the user can choose based on the level and the service, how to present the notification (e.g. popup notification for events from the battery monitor, and simple, non-disturbing, systray notification for Thunderbird events). All events will be logged and it's possible for the user to access/clear this log. In addition, you could allow the services to tag their messages using simple strings. For example with an instant messenger, if you're only interested about online/offline popup notifications about your friend Harry, you'd add a rule to the notification server saying it should display a popup for notifications tagged with "online-state-changed", "Harry". For easier usage, the notification server should allow its connected services to also modify certain settings. So, all the user would need to do is to right-click on Harry's buddy icon and toggle Tell me when Harry is online/offline. Of course, sane defaults should be choosen for the different services. Services would need to install an XML (or whatever) file to tell the notification server what they do, which events they provide and whats the default way of notification. This way you'll have a very flexible, but yet easy to use system. The average user will probably just stay with the (sane) defaults, while the more advanced users will reconfigure certain aspects. And the logging of the events ensures that you don't miss events while you're away. Does KISS mean nothing in today's open source world?
posted by Benedikt Meurer at
18:24
6 Comments:
I didn't read the libnotify-discussion and cannot judge this system's complexity. But your "desktop-syslog"-idea sounds good to me. Does something like this already exist in Linux desktop environments, e.g. Xfce?
And of course KISS does still matter in OSS, but like you, I'm sometimes a bit confused by GNOME design decisions...
By
Fabian, at 4/7/05 19:41
No, this doesn't exist in any current system and there's no spec. Just a few random thoughts.
By
Benedikt Meurer, at 4/7/05 20:01
First off, I like the syslog idea, and can imagine some interesting uses for such a system.
on a side note:
I wonder why think[g]s have to be that complicated all the time.
thinks in the above sentance should be "things".
not a big deal but I thought I would mention it :)
By
Anders, at 4/7/05 22:39
I really like the idea of a graphical syslog front end on Linux/Unix. Maybe the fact there currently is no gui front-end makes most people believe syslog is just for the server guys. I've done a web based interface to syslog, but that's quite a different story. I am currently implementing a new syslogd - rsyslog - and will keep this idea in my mind ... if only my Linux gui programming skills would be better ;)
By
Rainer, at 5/7/05 09:03
I wish for a change that people would read the specs we've being trying to get people to read before they comment on what can or can't be done.. I'll break this down.
Notifications have pre-defined levels of importance. A notification daemon could offer the user the option to filter based on this. Ours doesn't at this time. It's a simple reference implementation.
Applications send an application ID along to the notification. You could, in theory, turn off notifications inside the application. Also in theory, a daemon could let you turn them off inside the config as well, but that's a little trickier as we don't require registration for notification. However, there's also a class type that specifies the type of notification. These are standardized and a daemon could offer the ability to filter types out.
There's no reason a notification daemon couldn't do logging.
The one thing we may want to add later is more specific sub-types for notifications to narrow down what the user wants to see and what they don't, but they can generally get what they want by filtering the notification type.
It has been in our plans from close to the beginning to have a syslog eventually that logs each notification.
Everyone's so edgy when it comes to notifications, and the majority of the people who are against them because of "what they can't do" are people who have never even read the spec or sat down and talked with us.
By
Christian Hammond, at 5/7/05 18:52
Benedikt, I'd recommend doing the design from the ground up revolving around what you think notifications can do for people. I wrote about this several times before and again today, I've tried to approach this idea strictly from what you'd want to see as a person and how you'd want to interact with them. I hope it's useful to you, feel free to contact me if you're going to work on this.
By
Bryan, at 6/7/05 07:29
Post a Comment
<< Home