GNOME Bugzilla – Bug 697082
No efficient way to track which Individuals change status as favourites
Last modified: 2018-09-21 16:01:42 UTC
If a client wants to keep a working set of the Individuals which are favourites, the only option is to connect to notify::is-favourite on all Individuals. This obviously doesn't scale very well. We should add a property to IndividualAggregator like "Set<Individual> favourites" which will be valid (exhaustive) after the aggregator is quiescent. Clients that care about favourites generally want to do something with the set of favourites, so this would handle that case well in addition to the signalling. We could potentially add a special signal for the equivalent of individuals-changed, though it may be overkill as the set of favourites should be small enough that iterating through the set to handle just the changes should be fine. But if we care about the worst case, we should probably add favourites-changed.
I can see the use case, but I’m a bit wary of moving things like this into folks, since I can’t see a clear place to draw the line of which possible collections of Individuals are tracked by IndividualAggregator and which aren’t. How about a more general solution: add a IndividualAggregator::notify-individual signal which is emitted whenever an Individual tracked by the aggregator emits a notification? i.e. IndividualAggregator connects to Individual::notify on all individuals it tracks, and re-emits it (with the same detail string and a pointer to the Individual) from all individuals. The client in this use case could then connect to IndividualAggregator::notify-individual::is-favourite and track the set of favourites that way. It would still mean the client has code for tracking the set, but would eliminate the signal connection scaling problems.
Could be best/most-simply implemented as a search (bug #646808)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/folks/issues/58.