Auto layout crashes #3203
Description
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
- Create a model similar to the one created in Shared Objects between diagrams are deleted even when one still exists on the other diagram #3047
- Click on 'Tools' -> 'Auto Layout'
- See error
Error report
Gaphor version: 2.24.0
Operating System: Darwin (23.4.0)
Display: GdkMacosDisplay
Python version: 3.11.7
GTK version: 4.12.5
Adwaita version: 1.4.3
GtkSourceView version: 5.10.0
Cairo version: 1.18.0
Pango version: 1.50.14
PyGObject version: 3.46.0
Pycairo version: 1.26.0
pygit2/libgit2 version: 1.14.1 / 1.7.2
Errors:
Time since application startup: 0:00:28
|Traceback (most recent call last):
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/decorators.pyc", line 86, in async_wrapper
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/view/gtkview.pyc", line 284, in update
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/decorators.pyc", line 126, in wrapper
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphor/core/modeling/diagram.pyc", line 455, in update_now
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/connections.pyc", line 74, in solve
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/solver/solver.pyc", line 185, in solve
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/solver/constraint.pyc", line 105, in solve
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/constraint.pyc", line 211, in solve_for
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/solver/variable.pyc", line 111, in set_value
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/solver/variable.pyc", line 90, in notify
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/position.pyc", line 46, in _propagate_x
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/position.pyc", line 42, in notify
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphor/UML/actions/partition.pyc", line 53, in update_width
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/matrix.pyc", line 99, in set
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphas/matrix.pyc", line 53, in notify
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphor/core/modeling/presentation.pyc", line 134, in _on_matrix_changed
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphor/core/modeling/element.pyc", line 183, in handle
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphor/core/modeling/elementfactory.pyc", line 226, in handle
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphor/core/eventmanager.pyc", line 77, in handle
| File "/Applications/Gaphor.app/Contents/Frameworks/generic/event.pyc", line 61, in handle
|ExceptionGroup: Error while handling events (1 sub-exception)
└─┬──────────────────────────────╌┄┈
|Traceback (most recent call last):
| File "/Applications/Gaphor.app/Contents/Frameworks/generic/event.pyc", line 57, in handle
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphor/services/undomanager.pyc", line 319, in undo_reversible_event
| File "/Applications/Gaphor.app/Contents/Frameworks/gaphor/services/undomanager.pyc", line 153, in add_undo_action
|gaphor.services.undomanager.NotInTransactionException: Updating state outside of a transaction: Reverse event MatrixUpdated for element <gaphor.UML.actions.action.ActionItem element 23d197f0-dd91-11ee-9f87-be7f4daace3f>..
└─────────────────────────────╌┄┈
Expected behavior
Either an updated diagram, or all changes are reverted, without errors.
Screenshots
OS
- Linux (Please put in notes the specific distro)
- macOS
- Windows
Version
Version of Gaphor: 2.24.0
Additional information
It looks like this happens when item matrices are updated from the update cycle (solver).
This issue is rooted in a deeper issue: the view triggers an update of the underlying Diagram. This update is done asynchronously. Normally this works when moving or resizing an item, since the update handlers tend to get executed within the transaction (button press - button release). We're lucky here. However, when someone changes something (in a transaction) that schedules an update (outside of the transaction) we start to see those errors.
The updates that happen in the "background" should somehow be part of the transaction, or should be ignored.
We may be able to discard those changes, since those changes come from either the item's update function or the constrain solver. It would be better, and more consistent, to include those changes in the current (last) transaction.
There is a reason the (screen) update is done asynchronously: We can bundle changes together and reduce the number of constraint resolutions and redraws.