Notification popup alerts through dbus are possible with the kdbusnotification package.
The notify-send command is part of the libnotify package and used commonly in scripts and cron jobs to send popup notifications. Many distro maintainers install the package as part of the base system. The notify-send command is an acceptable method for testing the kdbusnotification daemon.
The current kdbusnotification implementation does not recognize or honor the notify-send expire-time parameter. An expire-time=0 parameter means the popup is persistent until explictly closed. An expire-time=10000 parameter will show the popup for 10 seconds and close.
Regardless of the notify-send timeout, TDE seems to always display a popup for about 6.5 seconds and then closes the message box.
The lack of honoring the expiration period probably affects other notification methods too.
From an admin perspective, an expire-time=0 parameter often is used to ensure the user does not miss a message when away or busy.
Steps to reproduce
First test:
Install the kdbusnotification package.
After logging in verify the daemon is running.
Send a notification with notify-send --expire-time=0 'Test' 'This is a test'.
The popup will close after about 6 to 7 seconds.
Second test:
Remove the kdbusnotification package.
Ensure a non TDE notification daemon is installed such as Xfce notifyd.
After logging in verify the daemon is running.
Send a notification with notify-send --expire-time=0 'Test' 'This is a test'.
The popup will remain open until explicitly closed.
Repeat either test with varying expiration times. The popup will always close with the fixed 6 to 7 second period.
Discussion
A default timeout is expected but also needs to be overridden when requested. There does not seem to be a GUI control for setting a default timeout. While the option is not required, the option seems common with other DEs.
Likely the dbusnotification package is only a conduit from dbus messaging to the TDE knotify service. Regardless, the kdbusnotifcation package needs to pass the expire-time parameter. The TDE knotify service needs to keep popups open for the desired time rather than what seems to be a fixed 6 to 7 seconds.
Unknown if required, but the kdbusnotification package does not install a dbus service file in /usr/share/dbus-1/services.
The service file probably is a requirement. Installing TDE in /opt/ purgatory should not affect function because the Exec= line of the service file is an explicit full path.
The service file would be created on-the-fly when building the package and replace $TDEDIR with an appropriate full file path such as /opt/trinity or /usr.
The service file must be installed to /usr/share/dbus-1/services and not to $TDEDIR.
The kdbusnotification daemon launches when starting the TDE session ($TDEDIR/share/autostart). Testing the notify-send command with the previous proposed service file did not resolve the timeout issues, but if the original daemon process is terminated then a message test shows a new process running using the full path specified in the service file. The proposed service file probably is good to go as is.
Two instances of the daemon is not desired. Any rework of the code should ensure only one instance per user is running. Nominal testing indicates multiple instances will run when there are multiple users, but only one instance per user should always be active.
The current work-around is ensure a compliant notification daemon is available.
## Basic information
- TDE version: ALL
- Distribution: ALL
- Hardware: N/A
## Description
Notification popup alerts through dbus are possible with the kdbusnotification package.
The notify-send command is part of the libnotify package and used commonly in scripts and cron jobs to send popup notifications. Many distro maintainers install the package as part of the base system. The notify-send command is an acceptable method for testing the kdbusnotification daemon.
The current kdbusnotification implementation does not recognize or honor the notify-send *expire-time* parameter. An expire-time=0 parameter means the popup is persistent until explictly closed. An expire-time=10000 parameter will show the popup for 10 seconds and close.
Regardless of the notify-send timeout, TDE seems to always display a popup for about 6.5 seconds and then closes the message box.
The lack of honoring the expiration period probably affects other notification methods too.
From an admin perspective, an expire-time=0 parameter often is used to ensure the user does not miss a message when away or busy.
## Steps to reproduce
**First test:**
1. Install the kdbusnotification package.
2. After logging in verify the daemon is running.
3. Send a notification with *notify-send --expire-time=0 'Test' 'This is a test'*.
4. The popup will close after about 6 to 7 seconds.
**Second test:**
1. Remove the kdbusnotification package.
2. Ensure a non TDE notification daemon is installed such as Xfce notifyd.
3. After logging in verify the daemon is running.
4. Send a notification with *notify-send --expire-time=0 'Test' 'This is a test'*.
5. The popup will remain open until explicitly closed.
Repeat either test with varying expiration times. The popup will always close with the fixed 6 to 7 second period.
## Discussion
A default timeout is expected but also needs to be overridden when requested. There does not seem to be a GUI control for setting a default timeout. While the option is not required, the option seems common with other DEs.
Likely the dbusnotification package is only a conduit from dbus messaging to the TDE knotify service. Regardless, the kdbusnotifcation package needs to pass the expire-time parameter. The TDE knotify service needs to keep popups open for the desired time rather than what seems to be a fixed 6 to 7 seconds.
Unknown if required, but the kdbusnotification package does not install a dbus service file in /usr/share/dbus-1/services.
The service file probably is a requirement. Installing TDE in /opt/ purgatory should not affect function because the Exec= line of the service file is an explicit full path.
A kdubsnotification service file candidate:
**File name:** org.tde.kdbusnotification.Notifications.service
**Contents:**
*[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=$TDEDIR/bin/notification-daemon-tde*
The service file would be created on-the-fly when building the package and replace $TDEDIR with an appropriate full file path such as /opt/trinity or /usr.
The service file must be installed to **/usr/share/dbus-1/services** and not to $TDEDIR.
The kdbusnotification daemon launches when starting the TDE session ($TDEDIR/share/autostart). Testing the notify-send command with the previous proposed service file did not resolve the timeout issues, but if the original daemon process is terminated then a message test shows a new process running using the full path specified in the service file. The proposed service file probably is good to go as is.
Two instances of the daemon is not desired. Any rework of the code should ensure only one instance per user is running. Nominal testing indicates multiple instances will run when there are multiple users, but only one instance per user should always be active.
The current work-around is ensure a compliant notification daemon is available.
I tried to implement a native TDE notification daemon based on DBus (dbus-1-tqt). TDE/kdbusnotification#4
It is/was more or less a PoC and I now see we had a long discussion about different details.
When looking into notification implementations in different applications, I came to the conclusion that most of them are implementing own notification handling (for example Skype or similar would receive and display notifications addressed to the application itself)
So the notification daemon (with DBus support) is standalone for such use cases as described here, where a script or external program which does not implement a notification handling may display notifications.
But back to the problem - could be that recently something on GTK side changed, because I see it is using gtk.
And why we do not move this discussion to the notification daemon?
I tried to implement a native TDE notification daemon based on DBus (dbus-1-tqt).
https://mirror.git.trinitydesktop.org/gitea/TDE/kdbusnotification/pulls/4
It is/was more or less a PoC and I now see we had a long discussion about different details.
When looking into notification implementations in different applications, I came to the conclusion that most of them are implementing own notification handling (for example Skype or similar would receive and display notifications addressed to the application itself)
So the notification daemon (with DBus support) is standalone for such use cases as described here, where a script or external program which does not implement a notification handling may display notifications.
But back to the problem - could be that recently something on GTK side changed, because I see it is using gtk.
And why we do not move this discussion to the notification daemon?
MicheleC
added this to the R14.1.x milestone 1 year ago
Added to R14.1.x milestone for the time being.
A fix may require an API change, so in that case we will need to evaluate wether it needs to be moved to R14.2.0 or not.
Added to R14.1.x milestone for the time being.
A fix may require an API change, so in that case we will need to evaluate wether it needs to be moved to R14.2.0 or not.
Basic information
Description
Notification popup alerts through dbus are possible with the kdbusnotification package.
The notify-send command is part of the libnotify package and used commonly in scripts and cron jobs to send popup notifications. Many distro maintainers install the package as part of the base system. The notify-send command is an acceptable method for testing the kdbusnotification daemon.
The current kdbusnotification implementation does not recognize or honor the notify-send expire-time parameter. An expire-time=0 parameter means the popup is persistent until explictly closed. An expire-time=10000 parameter will show the popup for 10 seconds and close.
Regardless of the notify-send timeout, TDE seems to always display a popup for about 6.5 seconds and then closes the message box.
The lack of honoring the expiration period probably affects other notification methods too.
From an admin perspective, an expire-time=0 parameter often is used to ensure the user does not miss a message when away or busy.
Steps to reproduce
First test:
Second test:
Repeat either test with varying expiration times. The popup will always close with the fixed 6 to 7 second period.
Discussion
A default timeout is expected but also needs to be overridden when requested. There does not seem to be a GUI control for setting a default timeout. While the option is not required, the option seems common with other DEs.
Likely the dbusnotification package is only a conduit from dbus messaging to the TDE knotify service. Regardless, the kdbusnotifcation package needs to pass the expire-time parameter. The TDE knotify service needs to keep popups open for the desired time rather than what seems to be a fixed 6 to 7 seconds.
Unknown if required, but the kdbusnotification package does not install a dbus service file in /usr/share/dbus-1/services.
The service file probably is a requirement. Installing TDE in /opt/ purgatory should not affect function because the Exec= line of the service file is an explicit full path.
A kdubsnotification service file candidate:
File name: org.tde.kdbusnotification.Notifications.service
Contents:
[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=$TDEDIR/bin/notification-daemon-tde
The service file would be created on-the-fly when building the package and replace $TDEDIR with an appropriate full file path such as /opt/trinity or /usr.
The service file must be installed to /usr/share/dbus-1/services and not to $TDEDIR.
The kdbusnotification daemon launches when starting the TDE session ($TDEDIR/share/autostart). Testing the notify-send command with the previous proposed service file did not resolve the timeout issues, but if the original daemon process is terminated then a message test shows a new process running using the full path specified in the service file. The proposed service file probably is good to go as is.
Two instances of the daemon is not desired. Any rework of the code should ensure only one instance per user is running. Nominal testing indicates multiple instances will run when there are multiple users, but only one instance per user should always be active.
The current work-around is ensure a compliant notification daemon is available.
I tried to implement a native TDE notification daemon based on DBus (dbus-1-tqt).
TDE/kdbusnotification#4
It is/was more or less a PoC and I now see we had a long discussion about different details.
When looking into notification implementations in different applications, I came to the conclusion that most of them are implementing own notification handling (for example Skype or similar would receive and display notifications addressed to the application itself)
So the notification daemon (with DBus support) is standalone for such use cases as described here, where a script or external program which does not implement a notification handling may display notifications.
But back to the problem - could be that recently something on GTK side changed, because I see it is using gtk.
And why we do not move this discussion to the notification daemon?
Added to R14.1.x milestone for the time being.
A fix may require an API change, so in that case we will need to evaluate wether it needs to be moved to R14.2.0 or not.