You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please Select if your Request is Either something new or an Enhancement
Enhancement of an existing Feature.
Request of a new feature.
Please select the area your request applys to. (Multiple selections are Possible)
Onboard. Initial vault setup and import/export pods
Create. Note creation, lookup, snippets and templates
Retrieve. Backlinks, references, graph view
Structure. Refactoring, multi-vault and schemas
Publish. Sharing your repo with the world
Misc (Choose this if your not sure)
Is your feature request related to a problem? Please describe
As I understand, the schema-added icons in the Dendron tree view perform a different role as compared to VSCode file type icons in its explorer view. Since every file has a type (even file with unknown types are given a placeholder icon), each entry in the explorer view will have an icon and folder icons can additionally indicate that something can be expanded:
In the Dendron tree, an icon just indicates a relation to an existing schema and both leaf and non-leaf nodes can have the same icons. Since not all nodes have icons, the tree view gets confusing at times when it's not possible to tell visually the structure of the node.
Consider this structure:
one
four
three
blah
foo
five
two
The above renders as follows:
In the image, the node two seems to belong to the node five which is not the case.
I think indenting of some nodes with icons and not indenting others leads to this confusion as node labels are not longer reliably aligned.
If all nodes are given an icon (even an empty square one), like in the explorer view, then the problem goes away, but the tree becomes too visually cluttered since most of the icons are not needed.
Describe the solution you'd like
As an alternative, I suggest moving the schema-added icon to the right of the node name which makes the hierarchy cleanly visible and schema icons scannable at a glance as they are right-aligned:
Additional context
As an added benefit, it would be harder to accidentally click the + button that creates an actual note from a stub. I'm not sure about others, but I often do that when working with the tree.
The text was updated successfully, but these errors were encountered:
Please Select if your Request is Either something new or an Enhancement
Please select the area your request applys to. (Multiple selections are Possible)
Is your feature request related to a problem? Please describe
As I understand, the schema-added icons in the Dendron tree view perform a different role as compared to VSCode file type icons in its explorer view. Since every file has a type (even file with unknown types are given a placeholder icon), each entry in the explorer view will have an icon and folder icons can additionally indicate that something can be expanded:
In the Dendron tree, an icon just indicates a relation to an existing schema and both leaf and non-leaf nodes can have the same icons. Since not all nodes have icons, the tree view gets confusing at times when it's not possible to tell visually the structure of the node.
Consider this structure:
The above renders as follows:
In the image, the node
two
seems to belong to the nodefive
which is not the case.I think indenting of some nodes with icons and not indenting others leads to this confusion as node labels are not longer reliably aligned.
If all nodes are given an icon (even an empty square one), like in the explorer view, then the problem goes away, but the tree becomes too visually cluttered since most of the icons are not needed.
Describe the solution you'd like
As an alternative, I suggest moving the schema-added icon to the right of the node name which makes the hierarchy cleanly visible and schema icons scannable at a glance as they are right-aligned:
Additional context
As an added benefit, it would be harder to accidentally click the
+
button that creates an actual note from a stub. I'm not sure about others, but I often do that when working with the tree.The text was updated successfully, but these errors were encountered: