Changes between Version 1 and Version 2 of Ticket #3285, comment 26
- Timestamp:
- May 27, 2020, 4:31:34 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #3285, comment 26
v1 v2 1 1 Unfortunately, blocking the trigger is probably the best short-term solution. It would be nice if the Model merely requested that the trigger be fired, and then later the trigger got fired more or less when the atomic changes trigger gets fired, but right now the actual firing of the trigger is a mess. It is defined in session.selection (a.k.a. core/selection.py) but fired by atomic.structure.StructureGraphicsChangeManager._update_graphics_if_needed(!) (and by the Model.selected property of course). Some kind of non-trivial revamp would be required to make this better, and it would involve the core. 2 2 3 I’ll put the revamp on my to-do list, but I’m sticking with trigger-blocking in the short term. FYI, ui _safe() does not delay the trigger at all if you are in the main thread already. It don’t know if any threads are setting Model.selected. It may have been implemented that way out of an abundance of caution.3 I’ll put the revamp on my to-do list, but I’m sticking with trigger-blocking in the short term. FYI, ui.thread_safe() does not delay the trigger at all if you are in the main thread already. It don’t know if any threads are setting Model.selected. It may have been implemented that way out of an abundance of caution. 4 4 5 5 —Eric