Open jolange opened 4 years ago
kozec
commented
4 years ago It is done to prevent spamming unlimited number of notifications on systems where that can end up covering entire screen. Maybe it can be configurable; How would dunst deal with 1000 notifications after updating 1000 small files?
jolange
commented
4 years ago You are right, spamming thousands of notifications is not clever. Dunst would also show them all. I also think grouping these as "Downloaded xxx files" is fine. In that case you just have to check the web interface for details.
But I don't understand the logic of the second version of the notification yet. If I update two files remotely, it says
That's then replaced by
What's the difference between these two? And why is the whole information still shown in the 2-file case, but in the 1-file case the second notification has less information?
I guess I'll have to have a closer look at the code and play around a bit.
When a file is updated remotely, a notification like this is shown, telling me that it has been updated now:
That's very useful. However, after a few seconds, it is "overwritten" by a notification like this:
Here, I can't see which files have been updated any more.
I'm using dunst and like to go back in the notification history to show older notifications that I was not quick enough to read. However, the first notification is no longer present in the history, because it has been "overwritten" by the second one. So I can only recover the second notification.
I think this is related to these lines, but I did not check out the code to change something yet. https://github.com/kozec/syncthing-gtk/blob/5c0e54283de1a6c12d047360b7aec8fb4c00cc4a/syncthing_gtk/notifications.py#L90-L94
Is there a specific reason to update the existing notification instance rather than creating separate notifications? For my use case the latter would be much better, but maybe there are good reasons to go with the other option. Any feedback would be appreciated!