thoughts on screen transition animations
we're unsure if the user/dev experience of transitions is nice right now and we feel like it could use some refactoring.
while they were intially conceptualized to be invisible to the application developer and just happen "magically" in the background, experience showed that the magic is broken when applications try to initialize during the animation period since the framerate goes through the floor.
to address this, the on_exit_done and on_enter_done methods were introduced which now make it explicitely the application developer's problem to deal with this. think can run from anywhere in between on_enter and on_exit_done at the moment, so if init has been moved to on_enter_done another flag (is that what .is_active is?) is required for think to know whether data is actually available. simple applications are not affected by this, but in many cases it becomes just another complication that the dev has to handle. super() calls need to be used inconsistently apparently (?).
there has been talk about adding a full_close method somewhere down the line, so the complications don't end here. since all the methods above were introduced after 1.2, we still have a chance to refactor this.
we have the following goals for this:
- applications should be able to be unaware of transitions again, even if they are complicated and have long inits and partial draws and whatnot
- applications should be able to be aware of transitions, but the namespace for those methods should not be super intertwined with system-like events such as open, close, full_close.
- think should strictly run only after/before app (de)init in the expected place (at the moment for example .on_enter_done() and .on_exit_done()
- in many scenarios we can't have animations without introducing artificial startup lag, so if users prefer a fast experience over a swipey one they should be able to turn animations off in the settings
we propose the following concrete steps:
- drop on_enter_done and on_exit_done again, on_enter should take place of on_enter_done
- restrict think to the new on_enter/on_exit frame, is_active reflects if it is within or not
- don't restrict draw but make it clear to devs to check is_active
- add optional methods draw_{enter/exit}_splash(ctx, n) with n being the animation progression [0..1] that replace the old on_enter and on_exit_done in spirit. if both those methods exist draw is restricted in the same way as think so that the is_active check can be dropped. these draws are called after the host draws happen so that users can un-shift ctx and draw on top if they feel like it to open up more interesting custom options.
- add animations toggle to the appearance menu
this would make the application api more concice and clear and also allow for some more interesting animations.