You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(If this sounds confusing, thats fine. I just write this here so I dont forget this. Will clarify things later)
I feel like I am reinventing the wheel here, but I found the following quite helpful when working with master components and it is not yet (fully) supported by the system:
Especially when implementing UIs for Tools what you end up with is wanting to have several elements in a morph be derived from the same component and the ability to control which component that is. What you essentially want is a way to control the master component conveniently for a larger set of morphs. Basically something like a class. I think it is quite obvious what the master component way for such a thing is: Just as when working with prototypes, you want to use an "intermediate" master component which all these morphs are derived from and which we can then tell to derive from different master components, effectively altering the master component for that large set of morphs.
Now you can actually already build such a component composition and locally it works quite well.
Trouble starts however when we want to make use of this variability for different instances of such a component.
Let me explain on a concrete example: I ran into this when I wanted to build a slightly altered version of the styling side bar.
The styling sidebar contains a huge number of number fields which all derive from the same master component. So I went and popped an intermediate master component between to conveniently control the master component for all of these: field_1 , field_2, .... field_n => intermediate_field => [dark_number_field | light_number_field]
Now when I created multiple copies of the side bar inside a world, there was however no convenient way to vary the appearance of all number fields for a side bar in isolation, since all of them still stuck to the same intermediate field.
So given side bars A and B, we had the following situation: A.field_1 , A.field_2, .... A.field_n, B.field_1 , B.field_2, .... B.field_n => intermediate_field => [dark_number_field | light_number_field]
But what we actually want is more something like: A.field_1 , A.field_2, .... A.field => A.intermediate_field => [dark_number_field | light_number_field] B.field_1 , B.field_2, .... B.field_n => B.intermediate_field => [dark_number_field | light_number_field]
Essentially making this intermediate component a concrete part of an instance that is not shared across all derived morphs of a master component. Currently there is no good way of achieving that, and I am wondering what would be the best approach. Maybe support for "scoped" master components? By that I mean that certain components have the ability to define "sub master components" which are considered local to the component and not the world they are defined in.
Or thought of in the other way: The ability to define "own" master components is no longer restricted to the world but can basically be done by any other component in a scene, following the "turtles all the way down scheme".
Updating this when I had time to think more about this.
The text was updated successfully, but these errors were encountered:
(If this sounds confusing, thats fine. I just write this here so I dont forget this. Will clarify things later)
I feel like I am reinventing the wheel here, but I found the following quite helpful when working with master components and it is not yet (fully) supported by the system:
Especially when implementing UIs for Tools what you end up with is wanting to have several elements in a morph be derived from the same component and the ability to control which component that is. What you essentially want is a way to control the master component conveniently for a larger set of morphs. Basically something like a class. I think it is quite obvious what the master component way for such a thing is: Just as when working with prototypes, you want to use an "intermediate" master component which all these morphs are derived from and which we can then tell to derive from different master components, effectively altering the master component for that large set of morphs.
Now you can actually already build such a component composition and locally it works quite well.
Trouble starts however when we want to make use of this variability for different instances of such a component.
Let me explain on a concrete example: I ran into this when I wanted to build a slightly altered version of the styling side bar.
The styling sidebar contains a huge number of number fields which all derive from the same master component. So I went and popped an intermediate master component between to conveniently control the master component for all of these:
field_1 , field_2, .... field_n => intermediate_field => [dark_number_field | light_number_field]
Now when I created multiple copies of the side bar inside a world, there was however no convenient way to vary the appearance of all number fields for a side bar in isolation, since all of them still stuck to the same intermediate field.
So given side bars A and B, we had the following situation:
A.field_1 , A.field_2, .... A.field_n, B.field_1 , B.field_2, .... B.field_n => intermediate_field => [dark_number_field | light_number_field]
But what we actually want is more something like:
A.field_1 , A.field_2, .... A.field => A.intermediate_field => [dark_number_field | light_number_field]
B.field_1 , B.field_2, .... B.field_n => B.intermediate_field => [dark_number_field | light_number_field]
Essentially making this intermediate component a concrete part of an instance that is not shared across all derived morphs of a master component. Currently there is no good way of achieving that, and I am wondering what would be the best approach. Maybe support for "scoped" master components? By that I mean that certain components have the ability to define "sub master components" which are considered local to the component and not the world they are defined in.
Or thought of in the other way: The ability to define "own" master components is no longer restricted to the world but can basically be done by any other component in a scene, following the "turtles all the way down scheme".
Updating this when I had time to think more about this.
The text was updated successfully, but these errors were encountered: