-
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
Create a node for the screen/homescreen group and add a visible property #827
Comments
This may be obsolete if instead we create a property that takes the value of the |
I thought we didn't want to go that direction because screens doesn't work after using studio. And we want clients to have all four screens available through the api which doesn't work if the api is limited to one screen. |
@kathy-phet the proposal is for there to be a Property that accepts a string formatted like the one used with the |
Implemented the Property for this (sim.general.view.screensStringProperty), and did a lot of the dynamic layout work above so that this should update seamlessly. One unintuitive thing is that you can currently be on a screen (1) and change the screens to (2,3) and it won't force a change of screens. I didn't know what was best (if I implement going to e.g. screen 2 in that case, it changes the focus in studio and makes things difficult). @arouinfar can you review behavior for this change? |
@zepumph would you be able to review these changes? Notably, selectScreens separation makes it particularly tricky, as we need the output of one section of it BEFORE we can create the HomeScreen. I had to add an earlier callback for this, but in general my solution is ugly in this way. Perhaps it would be best to separate selectScreens out into two functions? Thoughts? |
@jonathanolson I reviewed Presumably, the screens have been re-indexed upon startup. It looks odd, but seems acceptable given that
There are two cases where things get weird.
In case (1), it would be nice to set Similarly in (2), it would be nice to set However, in both of these situations, it seems rude to change I'm not sure what the best path forward is. It seems like we would need some complicated logic to have |
Yes, I was waffling back-and-forth between doing something (what you described) in those situations, or doing nothing. |
Just reviewed briefly, so sorry if I'm missing something.
|
I'm excited to discuss this this afternoon at 1:40, but basically my hope was to deprecate the ?screens query parameter as a PhET-iO feature, since this instrumented Property is a much more streamlined approach to support this both on startup AND for dynamic mutation during the runtime of the sim. |
There actually was an easy way to prevent the "reindexing", I've switched to it with the above commit. |
Future TODOs:
We renamed it to |
Also notably, having it just be a string "Property" doesn't work well. When trying to change "1,2" to "1,2,3", it goes through an intermediate "broken" state of "1,2," (extra comma), and fails validation. It seems like for most cases, an explicit list is fine. |
For the UI, I was picturing something like https://stackoverflow.com/questions/10588607/tutorial-for-html5-dragdrop-sortable-list which could look like: Maybe with grab handles so it looks more draggable. Also, the underlying type could be |
screensIncludedProperty will be
Add a linked element from the new navbar group so the visibleProperty links back to isUserNavigableProperty |
Implemented above, @samreid can you review? |
@jonathanolson the commits and behavior look good. I added a commit with a migration rule so 1.5 states will load into 1.6 gravity and orbits. There was one other flaw noted in https://github.com/phetsims/studio/issues/268 which was corrected. All else seems good to me. Tagging @zepumph in case he wants another look or knows of more to do. Otherwise, closing. |
As discovered in phetsims/chipper#946, there are TODOs in the code referring to this issue. Reopening. |
Fixed, closing. |
To make it easier for clients to mimic a one-screen sim, we will put the home screen plus screen icons/names into a node grouping container, and then instrument that grouping to be able to have visible property that can be toggled on and off. Optionally, an enabled property could be available too for clients to prevent premature movement to another screen ... but not sure that is needed.
@arouinfar - Can you look at the tree and work with @jonathanolson on implementation today/tomorrow?
The text was updated successfully, but these errors were encountered: