Skip to content
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

Single Property Tab that displays Properties of selected entity #419

Open
ThomasOrtner opened this issue Oct 1, 2024 · 5 comments
Open
Assignees
Labels
enhancement New feature or request

Comments

@ThomasOrtner
Copy link
Collaborator

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 ThomasOrtner added the enhancement New feature or request label Oct 1, 2024
@ThomasOrtner ThomasOrtner self-assigned this Oct 1, 2024
@ThomasOrtner
Copy link
Collaborator Author

@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
Copy link
Collaborator

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

something like that?

@ThomasOrtner
Copy link
Collaborator Author

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
Copy link
Collaborator

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
Copy link
Collaborator

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants