Mailinglist Archive: opensuse-features (829 mails)

< Previous Next >
[openFATE 305586] Desktop independent global notification framework
  • From: fate_noreply@xxxxxxx
  • Date: Thu, 9 Jul 2009 10:23:09 +0200 (CEST)
  • Message-id: <feature-305586-21@xxxxxxxxxxxxxx>
Feature changed by: Andreas Jaeger (a_jaeger)
Feature #305586, revision 21
Title: Desktop independent global notification framework

openSUSE-11.2: Evaluation
Priority
Requester: Important
Projectmanager: Desirable

Requested by: Stefan Assmann (assmannst)
Partner organization: openSUSE.org

Description:
Our current desktop environments lack a good, configurable notification
framework like Growl on Mac OS X. With D-BUS in place we could
develop/integrate a framework that is desktop independent and could
serve both KDE and GNOME applications the same way.
This provides one step towards integrating both desktops more closely,
thus making the user experience smoother.
One such notification system is already in development. It's called
mumbles (http://www.mumbles-project.org/) and provides lots of features
similar to Growl.
* It's customizable
* Has theming support
* Has plugin support
* Desktop independent
* Can use compiz for smooth display
Using such a framework, more than just integrating desktops could be
achieved:
* Local notifications on hardware events
* Remote notifications on login/hardware events
* Easy scriptability for custom notifications
Steps necessary to implement such a framework in openSUSE/SLE:
* Install and configure framework by default
* Integrate framework configuration in desktop environment
* Make framework interactive so the user can react on events (optional)
* Make applications D-Bus/Notification aware, so they send events,
already available: Firefox, Thunderbird, Pidgin, several others


Business case (Partner benefit):
openSUSE.org: Such a framework would be a huge win for the general user
experience, as it makes the desktop look more integrated and smooth.
It's even a good idea for SLES, so administrators can be easily
notified when events occur, without the hassle to set up syslog
forwarding+parsing+notifying.

Discussion:
#2: Guy Lunardi (glunardi) (2008-12-18 08:32:18)
I agree this is an important part of the desktop platform. How is this
different from the libnotify solution which I believe we use for this
purpose today?
It is my PM understanding it does most everything you are describing
including a CLI (notify-send).
Applications such as NetworkManager, PowerManager, Pidgin and Banshee.
Reading their FAQ, the reason for not using libnotify is that the
author wanted to put more Python dependent software on their system :-
).
Is this proposal about switching from libnotify to mumbles? (honestly
asking, I have no opinion)

#3: Stefan Assmann (assmannst) (2008-12-18 15:46:19) (reply to #2)
Honestly I have not much insighted into libnotify myself. Talking to
Alex Graf about this, we came up with the idea to teach the libnotify
daemon how to forward messages to mumbles. It turns out that libnotify
has support for theming, so it should be possible to create a theme
that forwards all events to mumbles. Then we would not have to make a
decision what we should use and could just switch and see what suits us
best. This way we don't lose any functionality.
In my opinion mumbles looks a lot smoother than the current libnotify
messages. However I guess everything possible with mumbles could be
tought to libnotify as well. Frankly said I don't want to make a
decision here, what I care for is that the functionality described in
this fate will be integrated into our products.

#4: Stefan Assmann (assmannst) (2008-12-18 16:15:56) (reply to #3)
Update: Talking to the developers I just learned that mumbles will
intercept libnotify messages and handle them. There's a plugin for
mumbles that does that.

#5: Tejun Heo (teheo) (2008-12-22 13:28:54)
I think that having the notion of what a "notification" is and how the
user can take "action"s to it is quite important. There are multiple
classes of notifications - some are ephemeral while others must get
acknowledgement from the user. For example, download complete from
firefox, new driver or codec installation suggestion and smartd
reporting imminent disk failures can and probably should use the same
notification mechanism but they need to be handled differently.
For ephemeral notifications, I think what libnotify has been doing is
fine but for anything else, we at least need a way for the user to ack
or take actions accordingly and review and search unacked and acked
notifications.
I think having such notification mechanism will help us a lot as a
distro as it will enable us to suggest things in not-too-intrusive yet
friendly way.

#6: M. S. (funkym) (2009-01-17 13:05:51)
libnotify does all that and ontop is based on a desktop independent
freedesktop specification
(http://galago-project.org/specs/notification/index.php) for
notifications to adopt by any desktop environment. It is written in C
which is much more suitable for daemons and provides bindings for D-
BUS, Mono, Python and Vala. Interactive notifications are already used
widely; take PackageKit as an example. The developer of growl is also
interested to improve libnotify as they are closely related and friends
with the maintainer. A cross desktop friendly notifications utility in
Python is the right thing to make things worse. If you want the bling
just create a different theme for libnotify... What libnotify needs
though is a bit of coding love to implement stuff like network
notifications. Switch to Mumbles -> NO! Contribute to libnotify -> YES!
$2c

#7: Stefan Assmann (assmannst) (2009-01-19 09:55:39) (reply to #6)
It's no longer the question whether to switch from one to the other.
Mumbles is able to intercept libnotify messages so we can provide it
"on top" and switch. Then it's a question of defaults and what we like
this to become.

+ #10: Andreas Jaeger (a_jaeger) (2009-07-09 10:21:44)
+ Ubuntu is working on a notification framework well
+ (https://wiki.ubuntu.com/NotifyOSD).
+ Are those in a state that we can make a decision to go one way or the
+ other?
+ Initially we could add it as optional package and ask for feedback with
+ Milestone 4 - and then decide what to do.



--
openSUSE Feature:
https://features.opensuse.org/305586

< Previous Next >
This Thread