Open ThomasOrtner opened 3 weeks ago
@haraldsteinlechner Do you have a suggestion towards a Multimodel PropertyWindow with regard to the mod system and model update view composition? I would suggest to build a toy example first with cubes and spheres in Media.
adaptive {
match! currentSelection with
| Surface -> yield! surfaceUI
| Annotation -> yield! annotationUI
}
something like that?
That might work, but for that we need a super union type that contains all possible entities. Actions that change properties are distributed in the update function. I guess we just have to try that, a toy example is to easy to see the implications. We can start with maybe just two entities Surface
and Annotation
and move forward from there.
well i think the decision (here a union) could be a more complex context aware condition computed from the relevant parts of the model. The only disadvantage is that larger portions of the ui need to be reconstructed when this condition changes. Making the UI invisible via css would get rid of this disadvantage.
So all in all, if conditions can be found to decide which gui should be used this should be quite easy, even porting from status quo to this setup is rather simple since the original UI can be re-used. (and possible wrapped into a dispatching message such as type ContextMessage = | SurfaceMessage ... | AnnotationMessage
which requires to list all possible UI sub components and handle them type safely in the update function.
Am i missing something?
what would be the most important single property tab aspect? what could we use to test it out? Just a properties tab wich either surface or annotation properties inside, right? what is another prime use case?
This was wished a long time ago by SteBan along with bulk change of properties. Currently the properties of selected items, be it a surface or an annotation, is realized as an according within the same tab typically below a grouped list of entities. Users have to select an item from the list, then close the according, find the property in the accordion below, change it, and then open the list accordion again.
Changing more than one instance in a long list is already rather cumbersome.
Suggestion to implement a single property tab, similar to visual studio properties, which is dynamically filled with the properties of the selected entity. This needs some thought regarding typing and coupling within the
Model
.