Realized something, after tracking refresh problems in a couple gramplets1 to signals being disabled before a massive operation (like an import or an extended-selection deletion) and re-enabled afterwards. (The gramplets were not connected to the <object>-rebuild signal, only the <object>-add, <object>-delete and <object>-update signals.)
I do not understand the logic behind the update signal. If it adds another “massive change” signal, shouldn’t the minor change signals resonate? It makes sense that some cpu-intensive tasks only trigger on major shake-ups of the Tree. But it seems like if an update is triggered by a minor tremor, a massive quake should be detected by that same trigger.
For instance – the db_changed in the backlinks.py doesn’t monitor for rebuilds. But it needs to include it because rebuild signals don’t automatically trigger the add, update or delete signals.
For large batch processes the signals are disabled for performance reasons. Rather than emitting thousands of person-update signals with the handles of the people who have been modified, it is quicker to emit a single person-rebuild signal. This just tells the front-end that so many people have been updated that it should rebuild the GUI elements that display people.
Ok. I understand the reasoning for disabling signals and sending the Rebuild signal after.
What I do not understand is why the person-rebuild signal doesn’t push a signal into the other signals too. So, if a routines are only monitoring person-add signal, they would trigger for person-rebuild too.
Isn’t it hierarchical? Just like the Place Hierarchy, when searching an Enclosing place, one expects all the enclosed places to be searched too.
No the signals serve different purposes. For performance reasons the front-end code needs to know if it is better to do a complete rebuild or to make a series of changes to given handles. Where the change is large, we might not even record the handles changed so it may not be possible to emit the individual update signals.
Then how should we test the hundreds of plugins (built-in and add-on) in the dozens of view modes with different forms of existence (dashboard, sidebar, bottombar, undocked, spawned windows) for where they refresh (or fail to refresh)?
Some are subtle, like: lists of Custom Filters (or Tags) in modeless (or semi-modal) dialogs that do not update when the definitions are tweaked elsewhere in the Interface. Some failures require gross changes to test. Sometimes, switching Trees. Othertimes, importing data or doing mass edits.
But there are too many variations to test manually.