mNo edit summary |
(→Owner) |
||
| (7 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
<!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --> | <!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --> | ||
= | = System Wide Desktop Notification <!-- The name of your feature --> = | ||
== Summary == | == Summary == | ||
<!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --> | <!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --> | ||
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 == | == 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: | * 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--> | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]] | * Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]] | ||
* Last updated: | * Last updated: 12 Dec 2009 | ||
* Percentage of completion: | * Percentage of completion: 00% | ||
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --> | <!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --> | ||
| Line 26: | Line 26: | ||
== Detailed Description == | == Detailed Description == | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
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 == | == 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. 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 == | == Scope == | ||
<!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
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 == | == How To Test == | ||
| Line 47: | Line 53: | ||
3. What are the expected results of those actions? | 3. What are the expected results of those actions? | ||
--> | --> | ||
# Log in to a default fedora desktop | |||
# Ensure /etc/rsyslog.conf has the line <code>*.emerg *</code> | |||
# Enter <code>logger -p emerg "Just Testing"</code> | |||
# Observe graphical notification message | |||
# Enter <code>shutdown -k now "Just Testing"; shutdown -c</code> | |||
# Observe graphical notification message | |||
# Enter <code>notify-send --system "Just Testing"</code> | |||
# Observe graphical notification message | |||
# Enter <code>wall "Just Testing"</code> | |||
# Observe graphical notification message | |||
== User Experience == | == User Experience == | ||
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | <!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | ||
Users will, when critical system events happen, see an alpha blended message box, which fades as it times out. | |||
== 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 == | ||
| Line 67: | Line 89: | ||
== Comments and Discussion == | == Comments and Discussion == | ||
* See [[Talk:Features/ | * See [[Talk:Features/SystemWideDesktopNotification]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --> | ||
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
- Log in to a default fedora desktop
- Ensure /etc/rsyslog.conf has the line
*.emerg * - Enter
logger -p emerg "Just Testing" - Observe graphical notification message
- Enter
shutdown -k now "Just Testing"; shutdown -c - Observe graphical notification message
- Enter
notify-send --system "Just Testing" - Observe graphical notification message
- Enter
wall "Just Testing" - 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.