Ben Hutchings <b...@decadent.org.uk> writes:
> On Wed, May 29, 2013 at 09:06:59PM +0200, Adam Borowski wrote:
>> On Wed, May 29, 2013 at 05:11:35PM +0200, Josselin Mouette wrote:
>> > Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a
>> > écrit : 
>> > > Take for example, smartmoontools [1]. Currently, if an end-user
>> > > installs smartmoontools and a hard-disk fails (i.e. smartd detects a
>> > > problem with one HD) he will *not* see any notification: the failure
>> > > is sent through local e-mail.
>> > 
>> > He will see a notification on his desktop. Clear, understandable and
>> > translated in his configured language:
>> > https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c
>> > (The code is different but already here in squeeze and wheezy.)
>> 
>> What you propose requires:
>> * adding desktop environment specific code to every facility that may need
>>   to send notifications
>> * adding such notifications to every other desktop environment
>
> Wrong, we already have org.freedesktop.Notifications in GNOME,
> KDE and Xfce.
>
>  So those two points become:
>
> * adding cross-desktop code to every facility that may need to send
>   notifications
> * adding a notification daemon to task-lxde
>
> There are libraries to help with the first point, of course.

Wouldn't a daemon watching /var/mail/root and turning any mail into
desktop notifications solve most of this, while still allowing the same
notifications to reach a sysadmin on non-desktop systems?

The issue that worries me most about these desktop notification plans is
the possibility that some package may decide to unnecessarily drop
support for non-desktop systems, adding dependencies on the desktop
notification system. I believe we already have had a few examples of
such unnecessary dependencies on services which are "nice to have", like
GNOME depending on NetworkManager for example.

The "Clear, understandable and translated in his configured language"
point is unrelated the notification system.  That requirement should be
at least as strict for any mail to root.


Bjørn


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871u8opye0....@nemi.mork.no

Reply via email to