-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AboutDialog should be created during startup #558
Comments
This is a slippery slope. Dialogs should generally be created on demand, and eagerly creating the About dialog doesn't address the problem generally. Are we also going to create the (optional) Options dialog? What are the alternatives? |
I'm confused. Reading https://github.com/phetsims/phet-io/issues/1454, it sounds like there's an intention to "support instrumented element that is dynamic/lazily created". Why is that not applicable to the About dialog? |
Why? Do they incur too much CPU time during startup? Too much memory usage on the heap? Better programming practice? Other runtime considerations?
The strategy we used for Group is to provide an archetypal element that completely describes the PhET-iO structure/api (subtandems and all) for members of the group. If we apply that pattern to dynamic/lazily created elements, then we might end up with something like this: create a "synthetic" About Dialog to signify the API structure, then when the button is pressed, create the "real" About Dialog. That plan creates 2x too many About Dialogs! I foresee the following possibilities: a) Create the dialogs and other things on startup (b) sounds complicated and brittle, so I wanted to investigate (a) more to see if it is feasible. In simulations, we often create dialogs lazily, but do not apply this practice to other parts of the sim. For instance in Wave Interference Screen 1, the simulation starts by showing the Water Scene, but the Sound and Light scenes are eagerly (not lazily) created. That is good because they become immediately interoperable for PhET-iO. I don't know how we've arrived at the policy of "create everything in the sim eagerly except for dialogs", but I'm inclined to investigate that as a pattern, including investigating the impact on heap and startup time. |
We are not creating everything eagerly, we are creating the initial state of all screens eagerly. We create screens eagerly because the time delay to create and switch to a new screen was determine to be (in general) unacceptable. It's assumed that students will visit each screen, and we decided that it was a preferable UX to have the cost to create all of the screen incurred on startup. Requiring everything to be created eagerly is imo an unacceptable limitation. It makes no sense to eagerly create things that may never need to be created. About dialog certainly falls into that category. The only reason we're having this discussion is that we've waited until far too late in this process to fully consider how PhET-iO works with dynamic creation. |
Some ideas on the spectrum from easy to difficult:
For the latter: if we reuse the same code for creating the "prototypes" as the real instances, it could look something like:
// Dialogs that could be constructed by the menu. The menu will create a dialog the
// first time the item is selected, and they will be reused after that. Must
// be created lazily because Dialog requires Sim to have bounds during construction
var aboutDialog = new AboutDialogScaffolding();// is eagerly created and has the API we want
var optionsDialog = null;
var updateDialog = null;
class AboutDialogScaffolding(){
create(){
if (this.dialog===null){
this.dialog = new AboutDialog(this.logo||null)/// no tandem
//or
this.dialog.setLogo(this.logo);
}
}
setLogo(logo){
if (this.dialog){
this.dialog.setLogo(logo)
}else{
this.logo = logo;
}
}
}
AboutDialogScaffoldingIO{
setLogo(logo){}
addListener(listener){}
}
// client
invoke('setLogo',myLogo) // eager
//.. This has the advantage that it keeps a lightweight item always in the API, but doesn't do the heavy lifting until necessary. However, because this involves uninstrumenting the instance (including 100% of its subtree), we lose all interoperability for the nested substructure. Including data stream, focusability, API calls, etc. |
We measured the size of the about dialog to be about 1MB, so we would like to create it lazily. Not sure what approach to use, it will depend somewhat how we want to see it in Studio, which is a question for PhET-iO design meeting. Do we want it to show in studio as "grayed out" where you can see the API but not interact with it until created? Is it OK to have 2 different ways of having non-existent things (groups + lazies)? Also, how will we combine these, like a group with lazy items. Or a lazy item structured under another lazy item? @chrisklus says maybe the about dialog could be streamlined to not take up 1MB. |
@kathy-phet suggests: let's not instrument the About Dialog for now. We can take time to make sure we design Group and/or Lazy things properly. |
Note that this will currently break phet-io/a11y together, see set focus( value ) {
// If in phet-io brand, a11y is enabled, and the focus is not null
if ( window.phet && phet.phetio && phet.chipper.accessibility && value ) {
var node = value.trail.lastNode();
assert && assert( node.isPhetioInstrumented(),
'When running phet-io mode, all focusable instances must be instrumented.' );
} |
In the above commits I made the following changes:
@samreid please review. |
Are values for |
Just for data stream output. Focus changes are downstream of Keyboard related input actions, so a11y input record playback works largely the same way as traditional input. |
// Special case for target since we can't set that read-only property. Instead use a substitute key.
if ( key === 'target' ) {
domEvent[ TARGET_SUBSTITUTE_KEY ] = eventObject[ key ];
} Why is Other changes look good, I'm just trying to understand the changes in Input.js better. |
Removing from blocks publication. |
Remarking as blocks publication because this seems it should be done for GQIO11 |
@chrisklus and I reviewed the changes and have a better understanding of |
From https://github.com/phetsims/phet-io/issues/1454, we would like to simplify the PhET-iO API by creating the about dialog during startup. But we would also like to postpone network activity until the dialog is shown, if that is not too much trouble.
Mentioning @jonathanolson because this overlaps with #557
Also, we should check that this doesn't put too much additional burden on the heap or startup time.
The text was updated successfully, but these errors were encountered: