|
46 | 46 |
|
47 | 47 | """
|
48 | 48 |
|
| 49 | +# ### Developer notes ### |
| 50 | +# |
| 51 | +# ## Linking of slicers |
| 52 | +# |
| 53 | +# The approach that has been taken is to let users create a VolumeSlicer |
| 54 | +# for each view to be created. To still allow different slicers to be |
| 55 | +# aware of each-other, we gratefully make use of dict-id's and pattern |
| 56 | +# matching inputs. This also adds a lot of flexibility to the number |
| 57 | +# of views that a user wants to create. To prevent all slicers in an |
| 58 | +# application to be linked, we introduce the concept of a scene_id, |
| 59 | +# which is simply a field in the dict ids to filter by. |
| 60 | +# |
| 61 | +# ## Synchronizing slicer figures |
| 62 | +# |
| 63 | +# It's tempting to let changes made in one slicer (e.g. changing the |
| 64 | +# slice index) to directly take effect in the other slicers. However, |
| 65 | +# this causes a lot of figure updates, which quickly makes the |
| 66 | +# interaction jerky. Instead, a rate-limited `state` is created, for |
| 67 | +# other slicers (and application code) to react to. This helps allocate |
| 68 | +# most CPU cycles for the interaction of the current slicer, creating |
| 69 | +# a smooth experience. For similar reasons, synchronizing e.g. view |
| 70 | +# ranges between multiple slicers would be challenging. |
| 71 | +# |
| 72 | +# ## The slider.value is part of the flow |
| 73 | +# |
| 74 | +# The slider can be used to set the index, but we also want to allow |
| 75 | +# setting the index from the outside. To avoid a circular flow, the |
| 76 | +# slider.value *is* the reference index. Therefore the slider must be |
| 77 | +# present in the layout, and must be hidden (not omitted) if the user |
| 78 | +# does not want it. It may be possible to work around this, but right |
| 79 | +# now this seems by far the easiest solution :) |
| 80 | + |
| 81 | + |
49 | 82 | import numpy as np
|
50 | 83 | import plotly.graph_objects
|
51 | 84 | import dash
|
|
0 commit comments