pro3d-space / PRo3D

PRo3D, short for Planetary Robotics 3D Viewer, is an interactive 3D visualization tool allowing planetary scientists to work with high-resolution 3D reconstructions of planetary surfaces.
http://pro3d.space/
GNU Affero General Public License v3.0
39 stars 2 forks source link

Single Property Tab that displays Properties of selected entity #419

Open ThomasOrtner opened 3 weeks ago

ThomasOrtner commented 3 weeks ago

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

haraldsteinlechner commented 3 weeks ago
adaptive {
     match! currentSelection with
     | Surface -> yield! surfaceUI
     | Annotation -> yield! annotationUI
}

something like that?

ThomasOrtner commented 3 weeks ago

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.

haraldsteinlechner commented 3 weeks ago

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 commented 3 weeks ago

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?