lib/events: added FolderNew and FolderRemove

[coderonline]

The new events are the most convenient way to implement folder emblems to integrate syncthing in file managers. My evaluation has shown, that gio (as successor of gvfs) can be used to set emblems in a portable way accross different file managers, like gnome-files and Thunar with

gio set -t stringv workspace metadata::emblems star-gold star-red

The trouble is, that these emblems are saved under .local/share/gvfs-metadata/ in a binary format and are persistent between logins. I have considered to monitor the syncthing configuration file for changes instead, but that would mean to compare the current folder list against an saved state in order to "detect" removed folders. That would of cause be error prone and I was unable to find any other event which can be used to inform listeners about the removal of folders. So this implementation seemed to be the easiest way.

As event names I have chosen FolderNew and FolderRemove after the corresponding functions rather than the log messages, in which a folder gets added or removed instead.

Testing

I have manually tested the new events and do not see a chance of any side effects, but I am open to suggestions of cause.

[acolomb]

I have considered to monitor the syncthing configuration file for changes instead, but that would mean to compare the current folder list against an saved state in order to "detect" removed folders. That would of cause be error prone and I was unable to find any other event which can be used to inform listeners about the removal of folders. So this implementation seemed to be the easiest way.

Why would it be error-prone to compare the list of folders? Because you don't yet have a persistent list of which folders have the emblem? Can you retrieve such a list from gio?

I think you need to consider how this works when Syncthing is not running. It should then not display any emblems, because nothing is really synchronized. And in that case the events won't help you because they're not generated. Even worse, the Syncthing config might get changed while it is offline, so you wouldn't even get a FolderRemoved event and be stuck with the emblems. So I think the only reasonable solution is to parse the config and compare against your own list of set emblems. You can subscribe to the ConfigSaved event to get notified, and do it once when your extension establishes a connection to Syncthing.

I would much prefer if there were a non-persistent way to display the icons, they really are of transient nature.

[coderonline]

I have considered to monitor the syncthing configuration file for changes instead, but that would mean to compare the current folder list against an saved state in order to "detect" removed folders. That would of cause be error prone and I was unable to find any other event which can be used to inform listeners about the removal of folders. So this implementation seemed to be the easiest way.

Why would it be error-prone to compare the list of folders? Because you don't yet have a persistent list of which folders have the emblem? Can you retrieve such a list from gio?

I cannot retrieve such a list, because gio does not offer any list commands afaik. It is only possible to ask gio about certain paths instead. The synchronization between the gio database and syncthing would then require, that my plugin also stores a synchronization state in order to know which paths have been added to the database, so that these can later be removed again. A third config file for the same thing? Wait... While explaining I see more and more why this is not such a good idea. It ignores some of the problems complexity, but it is still tempting on the other hand, because an unnecessary emblem can easily be fixed by any user and will probably not happen very often.

I think you need to consider how this works when Syncthing is not running. It should then not display any emblems, because nothing is really synchronized. And in that case the events won't help you because they're not generated. Even worse, the Syncthing config might get changed while it is offline, so you wouldn't even get a FolderRemoved event and be stuck with the emblems. So I think the only reasonable solution is to parse the config and compare against your own list of set emblems. You can subscribe to the ConfigSaved event to get notified, and do it once when your extension establishes a connection to Syncthing.

That is also a good point. I will try to find another way to use gio.

For that I have two ideas:

1. My current emblems seems to be in a file called ~/.local/share/gvfs-metadata/home and it could be possible to create a second file syncthing, which could then entirely be deleted when syncthing is not running by a filemanager plugin. That would make the implementation very simple.
2. There is tumbler, a daemon to create thumbnails for files. It could be possible to create folder icons in a similar way.

Both methods could make changes to Thunar necessary and trigger another who-is-responsible-for-what-deadlock. Lets hope for the best. I will investigate a little further in the other projects before I continue or close this merge request.

I would much prefer if there were a non-persistent way to display the icons, they really are of transient nature.

And me the same, but even without my use case I still think, that these events could be useful, e.g. when you have auto-accept enabled and want to be notified about new folders.

[acolomb]

Adding or removing a folder is essentially a change to the configuration, i.e. it only happens in combination with a ConfigSaved event. That's what one should subscribe to when needing such notifications, and compare it with a locally cached copy to examine what interesting changes have happened (in your case, the list of folders). I can see how depending on the config JSON format would be more involved than having separate events, but I'm not sure it's worth the duplication.

[AudriusButkevicius]

Agreed. These events don't seem to add much value