search

evilsocket / opensnitch

OpenSnitch is a GNU/Linux interactive application firewall inspired by Little Snitch.
GNU General Public License v3.0
10.98k stars 513 forks source link

kde plasma desktop notifications timeout #673

Closed alexjp closed 1 year ago

alexjp commented 2 years ago

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:

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 commented 2 years ago

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 commented 2 years ago

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

image

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

image

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 commented 2 years ago

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

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 commented 2 years ago

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 commented 2 years ago

ok, it might be easier to solve.

Revert any changes you made, and set mloop to qt: https://github.com/evilsocket/opensnitch/blob/cbc9d2a1a9e2d13f0866cbd6bc4cfa74457e4b85/ui/opensnitch/notifications.py#L43

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 commented 2 years ago

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:

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 commented 2 years ago

new findings:

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 commented 2 years ago

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 commented 2 years ago
  • 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 commented 1 year ago

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 commented 8 months ago

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