We currently have some kind of heuristic to provide an initial value for space view names, that roughly is:
"$ENTITY_NAME", when created from heuristic with a given, non-root space origin"/ ($SPACE_VIEW_TYPE)", when the space origin is /"/ (empty $SPACE_VIEW_TYPE)", when creating an empty space view
This is inconsistant, and bit-rots extremely quickly when the use starts editing the space view's content. Plus, (1) contributes to the beginners confusion that "space view ~= entity" in the blueprint tree view.
I propose to make that field Optional and update the UI so that some subdued text is displayed until the user actually sets a custom name.
The actual text could further be $SPACE_VIEW_TYPE view of $ENTITY_LAST_SEGMENT, where entity could be either the space origin, or something derived from the query (if it is simple) e.g.:
2D view of /Text Log view of debug3D view of points
If a suitable entity cannot be devised, the fallback would be $SPACE_VIEW_TYPE view, e.g. Dataframe view.
I further propose to forgo trying to stick a numbering scheme like we do currently (e.g. "/ (2D) (2)"). That numbering would have to be dynamic, which could cause confusion. Also, the synchronised hover/selection highlight should make it clear what corresponds to what. And if there really is confusion, then that's an encouragement for the user to name his views :)
We currently have some kind of heuristic to provide an initial value for space view names, that roughly is:
"$ENTITY_NAME", when created from heuristic with a given, non-root space origin"/ ($SPACE_VIEW_TYPE)", when the space origin is /"/ (empty $SPACE_VIEW_TYPE)", when creating an empty space viewThis is inconsistant, and bit-rots extremely quickly when the use starts editing the space view's content. Plus, (1) contributes to the beginners confusion that "space view ~= entity" in the blueprint tree view.
I propose to make that field
Optional and update the UI so that some subdued text is displayed until the user actually sets a custom name.The actual text could further be
$SPACE_VIEW_TYPE view of $ENTITY_LAST_SEGMENT, where entity could be either the space origin, or something derived from the query (if it is simple) e.g.:2D view of /Text Log view of debug3D view of pointsIf a suitable entity cannot be devised, the fallback would be
$SPACE_VIEW_TYPE view, e.g.Dataframe view.I further propose to forgo trying to stick a numbering scheme like we do currently (e.g. "/ (2D) (2)"). That numbering would have to be dynamic, which could cause confusion. Also, the synchronised hover/selection highlight should make it clear what corresponds to what. And if there really is confusion, then that's an encouragement for the user to name his views :)