Open iangilman opened 8 years ago
Perhaps next and previous events should be blocked while perspective transitions are happening.(?)
Not sure if this is the place for this, but one thing that would make these easier to coordinate, since there are some other rendering bugs (images swooping in from different locations than their outlines when they are drawn, items starting from the wrong place or taking parabolic arcs when changing modes or thumbsize in overview perspective): we could include a description of the type of change that initiated a data update, or otherwise wrap the main state container so that it communicates with a separate renderer through the dispatcher.
For example, instead of calling doRender
when the core state is set, we can emit an event through the dispatcher, the data for which could be the type of change (or "action") that occurred. That way we can listen for the data change (confirming that the records will be up to date), but also know the type of change that has occurred. This would make it possible to get rid of most of the if... && blah then
stuff, and react differently to things that just update properties (like thumbsize).
Good thoughts. I'm working on something a little like this...we'll see how it goes :)
You'll see some canvases fly over. This is because of the timing on the two-stage "animation + immediate" transition from overview to detail.
The good news is everyone ends up in the right place. Heck, maybe the extra movement is a reward for hitting the key so fast!