As discussed offline with Yana and Emil, we'd like to implement a notification service to allow any bundles to call when needed a method that would display some on-screen information to the users. The implementation of this service would be OS-dependant (eg: using Growl on MacOSX, or the systray on Linux and windows).
I enclosed a draft definition of the service. It's actually quite similar to the service defined for the systray. Several questions I'd like to ask to Yana & Emil:
- I'd like to put the service in service/notification unless you'd have a better name for the service
- The NotificationService would define several type of messages (by a mean of a static field, eg INCOMING_MESSAGE_TYPE, etc.): for example, one for the audio calls, one for the Instant Message, etc. This means that the service may be extended each time a bundle would need to define a new class of message. Is this acceptable? I think this would be useful, so the implementation of the service could allow the user to select which type of messages it would like to display or not.
- The NotificationEvent would have the coordinated where the user clicked. Is it necessary to have other things? (eg: the message that was displayed, or its type?).
- For the implementation, I'd put the sources in
- All the current code that takes care of displaying on-screen messages (ie the listener code currently located in the growlnotification and the systray plugins) would need to be moved to a new bundle common to all OS, and that would listen to any kind of events (MessageListener, etc.) and call the notification function from the notification service. Any idea for the name and location of such bundle?
notification.zip (4.84 KB)
Louis Pasteur University - Networks and Protocols Team