Re: system Desktop notifications
- From: Rolf Fokkens <rolf rolffokkens nl>
- To: Zbigniew Jędrzejewski-Szmek <zbyszek in waw pl>
- Cc: desktop-devel-list gnome org
- Subject: Re: system Desktop notifications
- Date: Mon, 23 Jun 2014 23:10:14 +0200
Thanks for the feedback. I can understand that it may not always be
helpful indeed.
Let me refrase my question: Wouldn't it be useful that some system
related messages (backups, SMART...) are presented to "whom it
concerns"? The users whom it conserns could be:
- The (workstation) owner. So most likely the graphical console, the
local X server should present the messages. And maybe even when no user
is logged on, so a message popup on top of the login screen? Could be
helpful.
- The sysadmin. That might be whoever is in the wheel group. And it
doesn't matter if he's working remote or local;
- Subscribers? Maybe users should be able to subscribe to this kind of
information.
It's like when working in character mode: kernel messages show up on
(local) consoles. With wall it's possible (for the sysadmin) to write a
message to all users (who allow this). Something like that, but then in
the wordt of graphical consoles. I think this might be useful in
general, and maybe for backups in particular.
I was thinking about (system) dbus as the solution: the session manager,
the (local?) login screen or the notifier deamon can subscribe to a
notification service on the system dbus.
But considering dbus may have been wrong. Maybe there are good
alternatives, suggestions are welcome.
Rolf
On 06/23/2014 07:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 23, 2014 at 11:38:43AM +0100, Simon McVittie wrote:
On 22/06/14 19:31, Rolf Fokkens wrote:
For a udev driven backup script (connect the USB the disk, and the
backup starts) I'd like to have desktop notifications that say when the
backup starts and when the backup is finished so users can disconnect
the USB disk.
Consider, for instance:
* Alice is a sysadmin, Bob is an unprivileged user. Alice is logged-in
locally, Bob is logged-in remotely. Who should be notified?
(I think "Alice but not Bob".)
* The same users, but now Alice is remote and Bob is local. Who should
be notified? (I'm not sure.)
If you think the answer to the second is "Bob, because, most likely,
he's the one physically plugging in the USB disk" then something at the
level of gvfs (running inside Bob's session) might be a better solution.
If you think the answer to the second is "Alice, because she's the
sysadmin" then the Unix syslog, or the systemd Journal that extends and
partially supersedes syslog on systemd systems, might be a good basis
for an answer.
Something similar has been requested for SMART messages [1]. The
implementation should be quite similar.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=723108
Zbyszek
Google is helpful, but seems to tell me that these notifications work
via the session dbus, not the system dbus. Apparently a solution is to
identfy any logged on user, find the related DBUS_SESSION_BUS_ADDRESS
and use that to notify the user.
System-level components injecting events into an arbitrarily-chosen user
session, or (slightly better) into each user session, is not how the
system/session split in D-Bus is intended to work. The intended way to
do this within D-Bus is to run some process in each user session, which
does something on the system bus (subscribes to broadcast notifications,
or explicitly requests unicast notifications if there's private data
involved) and produces popups or whatever.
There is currently no spec for a generic notification-receiving daemon
that does that on the system bus.
Consider whether every logged-in user should get these notifications
regardless of their level of privilege - broadcasts on the system bus
are not access-controlled, and anyone (or anything - system users too)
can see them.
Also consider what should happen if nobody is logged in...
S
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]