Improving desktop notifications

[bebehei]

Currently, the desktop notifications are designed this way:

• Syncthing has sends an event
• The callback composes the message
• The message gets sent via the info method and gets displayed as a notification

So, it's currently only a single direction in the information way. The user can't actually use the notifications interactively, while the desktop standard proposes a feature called "Actions", which give the user an opportunity to react to notifications.

This would fit perfectly for the notifications, which are covering "Unexpected Folder/Device", where you could automatically open the dialogue to add or ignore the other devices. You don't have to open up syncthing-gtk manually and search for the device.

---

Also, the notification spec has a feature to replace notifications (the Replaces ID field). With that you can replace the content of already sent notifications. Currently the syncthing-gtk notification process queues up the synced files and waits a few seconds until a new notification will get sent.

So, every five seconds, syncthing-gtk sends out a new notification. Depending on your notification daemon, these notifications either pile up and get displayed sequentially or get displayed together simultaneously. And ofthen they still show up quite longer than the sync already finished.

I'd propose to save the notification object per folder and update the text accordingly.

---

I claim to be able to implement these things. Will you accept a PR in this field?

[kozec]

I claim to be able to implement these things. Will you accept a PR in this field?

Yes, it sounds like good idea :) How well is Replaces ID supported? Wouldn't it cause thousands of messages on KDE or other desktop?

[bebehei]

Sorry, for the long delay, I had been off for the weekend.

I'm not intending to replace the current buffer mechanism. I think it's a good thing, that syncthing-gtk currently waits 5 seconds until it actually sends a notification. Sending a single notification for each file and updating the text causes to much unnecessary load on the DBus connection.

I'd like to change the stuff that way:

status quo

1. File event comes in.
2. Notification timer starts
   • (some additional file events may come in)
3. notification gets sent with the current status in the events
4. file name lists get emptied in the python script
5. begin above

desired status

1. file event comes in
2. File event comes in.
3. Notification timer starts
   • (some additional file events may come in)
4. if first time: create a new notification and save it with the folder id
5. update the text of the notification
6. begin above

The important bit is, that you don't create a new notification every time.

Sorry, I'm short on time right now. I'll attach some screenshots tomorrow and answer the questions left.

[kozec]

So far it sounds good :) I've checked and it looks like Replaces ID is supported on every DE I could think of, so that shouldn't be a problem.

[bebehei]

Yes, the replaces id is a mandatory thing of the standard. TBH it's very easy to support such a feature.

What's not the mandatory part of the standard, but pretty useful: Actions. Most of the notification daemons support them.

So, if a new device shows up, you can just click on the notification and you'll get brought directly to the pre-filled DeviceEditorDialog window:

So, this looks like a normal notification:

And if you hover on it, you can automatically select an action: