PRo3D icon indicating copy to clipboard operation
PRo3D copied to clipboard

Single Property Tab that displays Properties of selected entity

Open ThomasOrtner opened this issue 1 year ago • 5 comments

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.

ThomasOrtner avatar Oct 01 '24 18:10 ThomasOrtner

@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.

ThomasOrtner avatar Oct 01 '24 18:10 ThomasOrtner

adaptive {
     match! currentSelection with
     | Surface -> yield! surfaceUI
     | Annotation -> yield! annotationUI
}

something like that?

haraldsteinlechner avatar Oct 01 '24 20:10 haraldsteinlechner

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.

ThomasOrtner avatar Oct 02 '24 08:10 ThomasOrtner

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?

haraldsteinlechner avatar Oct 02 '24 11:10 haraldsteinlechner

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?

haraldsteinlechner avatar Oct 02 '24 11:10 haraldsteinlechner