From Fedora Project Wiki
 
(5 intermediate revisions by the same user not shown)
Line 13: Line 13:
== Owner ==
== Owner ==
<!--This should link to your home wiki page so we know who you are-->
<!--This should link to your home wiki page so we know who you are-->
* Name: [[User:iandall| Ian Dall]]
* Name: Ian Dall


<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
* Email: <ian@beware.dropbear.id.au>


== Current status ==
== Current status ==
* Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]]  
* Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]]  
* Last updated: (DATE)
* Last updated: 12 Dec 2009
* Percentage of completion: 00%
* Percentage of completion: 00%


Line 31: Line 30:
== Benefit to Fedora ==
== Benefit to Fedora ==
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
Currently "wall" is effectively broken in all unix based systems due to the paradigm shift from terminal interaction to graphical desktops. This deficiency has been hidden to some extent by the common practice of having leaving terminal windows open. However as this becomes less common, the impact of the deficiency becomes greater.  
Currently "wall" is effectively broken in all unix based systems due to the paradigm shift from terminal interaction to graphical desktops. Programs such as "shutdown" send messages which are expected to be seen by all logged in users, but are not. This deficiency has been hidden to some extent by the common practice of having leaving terminal windows open. However as this becomes less common, the impact of the deficiency becomes greater.  
This feature will allow users of graphical desktops to see critical messages which they might currently miss. The need to deliver this messages is especially relevant in multi-user or enterprise environments, which might include multiple users on graphical desktops via thin clients.  
This feature will allow users of graphical desktops to see critical messages which they might currently miss. The need to deliver this messages is especially relevant in multi-user or enterprise environments, which might include multiple users on graphical desktops via thin clients.


== Scope ==
== Scope ==
Line 56: Line 55:


# Log in to a default fedora desktop
# Log in to a default fedora desktop
# Ensure /etc/rsyslog.conf has the line "*.emerg      *"
# Ensure /etc/rsyslog.conf has the line <code>*.emerg      *</code>
# Enter "logger -p emerg "Just Testing"
# Enter <code>logger -p emerg "Just Testing"</code>
# Observe graphical notification message  
# Observe graphical notification message  
# Enter "shutdown -k now "Just Testing"; shutdown -c"
# Enter <code>shutdown -k now "Just Testing"; shutdown -c</code>
# Observe graphical notification message  
# Observe graphical notification message  
# Enter "notify-send --system "Just Testing"
# Enter <code>notify-send --system "Just Testing"</code>
# Observe graphical notification message  
# Observe graphical notification message  
# Enter "wall "Just Testing""
# Enter <code>wall "Just Testing"</code>
# Observe graphical notification message  
# Observe graphical notification message
 
 


== User Experience ==
== User Experience ==
Line 74: Line 71:
== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
This would not be a new package but would requires coordinated changes across several packages. With the proposed implementation, these would be: xfce4-notifyd, rsyslog, upstart, libnotify and sysvinit-tools.


== Contingency Plan ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
These changes should be able to be introduced without disrupting existing behaviour. In the event that a change does disrupt exiting behaviour, revert the change.
Also the changes can be phased. For example: change xfce-notifyd and libnotify first, then change rsyslog, shutdown etc.


== Documentation ==
== Documentation ==

Latest revision as of 05:51, 12 December 2009


System Wide Desktop Notification

Summary

Currently there is no standard way for system (or LAN) wide messages to be delivered to users in a desktop environment. The traditional utilities "wall" and "rwall" only work for users who have open shell windows. While there are a variety of ways of delivering desktop notifications, none of these are convenient for system level notification.

Owner

  • Name: Ian Dall


Current status

  • Targeted release: Fedora 42
  • Last updated: 12 Dec 2009
  • Percentage of completion: 00%


Detailed Description

The traditional "wall" works by trawling through utmp and finding the tty's of logged in users, then writing a message to that tty. The same mechanism is apparently used by "shutdown" and "syslog". There needs to be a way for shutdown, syslog and admin scripts to send a message which is almost guaranteed to be seen by all logged in users.

Benefit to Fedora

Currently "wall" is effectively broken in all unix based systems due to the paradigm shift from terminal interaction to graphical desktops. Programs such as "shutdown" send messages which are expected to be seen by all logged in users, but are not. This deficiency has been hidden to some extent by the common practice of having leaving terminal windows open. However as this becomes less common, the impact of the deficiency becomes greater. This feature will allow users of graphical desktops to see critical messages which they might currently miss. The need to deliver this messages is especially relevant in multi-user or enterprise environments, which might include multiple users on graphical desktops via thin clients.

Scope

Many of the elements exist. There are several ways of actually displaying a message on the desktop, but xfce4-notifyd works pretty well and is used for desktop notifications within a session.

Currently xfce4-notifyd only listens to the d-bus session bus. If it listened to the d-bus system bus as well, and libnotify were modified to optionally use the system bus then the feature would mostly be implemented. Additionally the "notify-send" utility would need an option to use the system bus. The "shutdown" utility and the "rsyslog" daemon would need to be modified to send notifications on the system bus as well. Possibly "wall" should be modified as well so that scripts which already use wall can reach graphical desktop users without change.

How To Test

  1. Log in to a default fedora desktop
  2. Ensure /etc/rsyslog.conf has the line *.emerg *
  3. Enter logger -p emerg "Just Testing"
  4. Observe graphical notification message
  5. Enter shutdown -k now "Just Testing"; shutdown -c
  6. Observe graphical notification message
  7. Enter notify-send --system "Just Testing"
  8. Observe graphical notification message
  9. Enter wall "Just Testing"
  10. Observe graphical notification message

User Experience

Users will, when critical system events happen, see an alpha blended message box, which fades as it times out.

Dependencies

This would not be a new package but would requires coordinated changes across several packages. With the proposed implementation, these would be: xfce4-notifyd, rsyslog, upstart, libnotify and sysvinit-tools.

Contingency Plan

These changes should be able to be introduced without disrupting existing behaviour. In the event that a change does disrupt exiting behaviour, revert the change.

Also the changes can be phased. For example: change xfce-notifyd and libnotify first, then change rsyslog, shutdown etc.

Documentation

Release Notes

Comments and Discussion