kde plasma desktop notifications timeout

[alexjp]

Describe the bug
Thank you for opensnitch!
I am using it on kde plasma, with desktop notifications. But in plasma, the desktop notifications (not the popup boxes) are "permanent", meaning that they don't have a timeout.

I was able to make them temporary by commenting the timeout settings in the notifications.py file.
Is it possible to auto detect if using plasma and remove the timeout settings (so that they are temporary), or make an option for it?

Include the following information:

• OpenSnitch version. -> opensnitch 1.5.1-1.1
• OS: [e.g. Debian GNU/Linux, ArchLinux, Slackware, ...] -> Garuda Linux (Arch based)
• Version [e.g. Buster, 10.3, 20.04]
• Window Manager: [e.g. GNOME Shell, KDE, enlightenment, i3wm, ...] -> KDE Plasma
• Kernel version: echo $(uname -a) -> Linux stormtrooper 5.18.5-zen1-1.1-zen ZEN SMP PREEMPT_DYNAMIC Sat, 18 Jun 2022 11:56:24 +0000 x86_64 unknown unknown linux

To Reproduce
Enable the desktop notifications on opensnitch gui.
Wait for opensnitch to write a new rule, and show a desktop notification

Expected behavior (optional)
When opensnitch shows a notification, it should auto disappear by the normal timeout. If any more info is needed, plasma has the notifications history or one can simple check the "events" on opensnitch gui.

Thank you!

[gustavo-iniguez-goya]

Hi @alexjp !

mmh, I think that it depends on the KDE configuration. As far as I remember on KDE/OpenSuse/kubuntu the timeout works just fine, while on others the pop-up is not hidden after the timeout.

I'll try to reproduce it. Maybe it's something related with the connection to DBus.

[gustavo-iniguez-goya]

KDE has a timeout of 5 seconds to hide system notifications (Notifications -> Application Settings):

On a kubuntu 21.04 livecd it works as expected, notifications are automatically closed:

However I've got a kubuntu VM installed to disk from the same .iso file, and the notifications are not automatically closed.
No idea why. I'll take a look.

[gustavo-iniguez-goya]

I've got a solution for this problem. Right now there're 3 timeouts:

• Pop-ups timeouts (defaults to 15s)
• System notifications timeout (defaults to pop-ups timeout, 15s)
• KDE notifications timeout (5s by default)

I propose to set an extra timeout of (pop-ups timeout * 2), to close our system notification just in case everything else fails.

What do you think @alexjp ?

(I've tried out to lower the urgency level of the notifications, but it didn't make any difference)

[alexjp]

Sorry... I was out and unable to answer sooner!! Sorry!
Thank you for you trouble of testing, I should have tested in an older version of Plasma, since I am running git version.

I propose to set an extra timeout of (pop-ups timeout * 2), to close our system notification just in case everything else fails.
What do you think @alexjp ?

Well, I would sugest an option that would be: "Use default desktop timeout", which would not set the timeout in the notifications (which seems to be what is causing the issue ).

Also, while looking at the code and testing stuff, I noticed in "pynotify2" that is deprecated:

Pynotify2 is deprecated. Here are some alternatives:

    [desktop_notify](https://pypi.org/project/desktop-notify/#description) is a newer module doing essentially the same thing.
    If you're writing a GTK application, you may want to use GNotification ([intro](https://developer.gnome.org/GNotification/), [Python API](https://lazka.github.io/pgi-docs/#Gio-2.0/classes/Notification.html))
    For simple cases, you can run notify-send as a subprocess. The [py-notifier](https://pypi.org/project/py-notifier/) package provides a simple Python API around this, and can also display notifications on Windows.

I will try to look at the commits on kde to see what could have changed in the notification system !

Thank you!

[gustavo-iniguez-goya]

ok, it might be easier to solve.

Revert any changes you made, and set mloop to qt:

opensnitch/ui/opensnitch/notifications.py

Line 43 in cbc9d2a

mloop = 'glib'

The thing is that in some KDE Installations, setting the mainloop to 'qt' prevented system notifications from working, that's why I left glib.

[alexjp]

I reverted everything and changed mloop from 'glib' to 'qt'.

findings: it works if "popups" are enabled and I set the timeout. the timeout number is working properly.

there is an issue though: If i disable popups and leave only desktop notifications, the timeout number is disabled, and the notifications stop disappearing.

Could there be a timeout for popups and another for notifications ? or more simple, just make the timeout of the popups not be disabled when "popups" aren't enabled ?

tl;dr:

• enable an option to make "mloop = 'qt'"
• a timeout when "popup boxes" are disabled ( would be nice, since I actually prefer a shorter timeout for these notifications )

what do you think ?

( btw... but a separate issue, but the popups are always appearing in the center, even when configured to appear in another place, might be because i have multiple monitors )

[alexjp]

new findings:

• disabling popups but editing settings.conf and making default_timeout > 0, makes the popups appears, even though they keep disabled in the gui.

and idea: about the popups, maybe giving these popups a special class or title, one can make a kwin rule for it, hence solving some issues (like positioning)

[alexjp]

another finding, or "i think i am going crazy":

I tried editing the timeout value directly in notifications.py ( instead of reading the settings.conf key, hardcoding it to a value ). and notifications still didn't disappear.

So I tried reverting everything, even the mloop = 'qt' ( making it 'glib' again )... and not disabled the popups. and it worked. it seems it just doesn't work if I have desktop notifications while popups are disabled !

does this help in someway ?

EDIT more findings:

with popups enabled and qt notifications -> everything works properly
with popups enabled and system (Use system notifications option) notifications -> it seems to still be timing out, but the value is not the same as the seconds configured. my suspicion is that the multiplication by 1000 is really making it wait 5000 seconds. (in the case of 5 seconds)

[gustavo-iniguez-goya]

• enable an option to make "mloop = 'qt'"
• a timeout when "popup boxes" are disabled ( would be nice, since I actually prefer a shorter timeout for these notifications )

The DBus mainloop should be automatically choosen, for example by reading the environment variable XDG_CURRENT_DESKTOP (maybe Qt already has a helper to get the current DE). If it's KDE, lxQt, etc.. use qt. If it GNOME, Xfce, etc, use glib. If it fails, initialize it without a mainloop.

The system notifications timeout should be controlled by the Desktop Environment. On KDE if we connect properly to the DBus server, the value from System settings -> Notifications -> Hide after ... should be respected.

If i disable popups and leave only desktop notifications, the timeout number is disabled, and the notifications stop disappearing.

Correct. No idea why, but it shouldn't happen.

disabling popups but editing settings.conf and making default_timeout > 0, makes the popups appears, even though they keep disabled in the gui.

Well, that's because disabling the pop-ups sets the timeout to 0 :) so it's the expected behaviour.

In general I think that we already have too many options. If users can personalize part of our behaviour from the DE's settings, it'll be a better usage experience, because they should be used to change it from there (like KDE -> System Settings -> Notifications).

[gustavo-iniguez-goya]

hi!

I think this issue is fixed on v1.6.0. Now the notifications timeouts are handled by the Desktop Environment (by the dbus server that is in use), and closed after the configured timeout on the DE's preferences.

One downside I think is that on some DEs, the notifications are not added to the list of notifications on the systray. On cinnamon and gnome it works as expected, but on KDE it doesn't seem to work.

[petterreinholdtsen]

Note, this issue is reported as https://bugs.debian.org/1037114 in Debian where it is still unsolved.