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
Your latest addition of displaying parent namespaces to the NaviBar and general functionality improvements you have done to the NaviBar recently suggested to me a possible, more holistic approach of using NaviBar as a kind of super-source-code navigator, which really shines with bigger code bases.
In particular 2 major areas stand out:
Area 1: Tree View instead of List View
The idea is basically to replace the current ListView/ListBox-like control that lists subitems (namespaces, types, etc.) linearly with a tree-like control. Most likely this feature makes sense only for parent namespace elements in the NaviBar (since the current type's sub elements (nested types, methods, members) are already listed in the list directly as part of a current file or other partial files).
The way it would work for Namespaces as well as for Types not defined in the currently opened document is basically that each such item (representing either a Namespace or a Type in the dropdown) would be turned into expandable tree item, which, when clicked would dynamically expand and show its members (other namespaces and types for namespaces, and nested types and members for types). These nested subitems, in turn may too be expandable if they have any logical subitems.
So for example, assuming we have A.AB.TypeAB1.cs opened and there exists a type A.AC.TypeAC2.cs, when a user clicks on the A parent namespace node on the NaviBar, he would see AB and AC namespaces in the dropdown. These should be rendered as expandable items since both of them are namespaces that contain types. So, when user expands AC namespace item, it would list TypeAC2 as a subitem, which, in turn, too can be expanded further to reveal TypeAC2's members.
I have no idea how hard it is to turn a ListView into a dynamic TreeView like this, so I don't expect this be done anytime soon, but I thought I would share this idea. I find it would make code navigation / understanding even better!
Area 2: Tree Grid instead of Tree View
Expanding on the idea of a Tree above. Even better would be to make it into a Tree Grid, i.e. a tree with multiple, header-sortable, and perhaps even filterable columns.
The current design has a small toolbar at the top of every NaviBar dropdown where user can search by name and filter by item type (like classes vs structs vs enums). An alternative and a more flexible approach would be to merge that toolbar with a clickable Tree Grid / Grid header. Clicking on the header of a column would show basically 2 options: 1) sort by directions 2) filter (a menu with checkboxes for example that list all possible variants). So the idea is to make it very similar to how MS Access does it for example in its tables.
So, this way instead of having just one column (basically item name with syntax), there would be more columns, all of which could be sorted by / filtered by:
Item Type (namespace, class, struct, etc.)
Project / Assembly Names
File count
Line count
Something else?
Final Thoughts
Both of these areas can be done independently of each other. Meaning, if easier, it's possible to start with Area 2 and add tree capabilities later on.
Both of these features would enable a much better understanding of a big codebase.
NaviBar can thus be extended to be a replacement / a much better version of VS's Class View window.
Thanks.
The text was updated successfully, but these errors were encountered:
Thank you very much for your suggestions.
Currently Visual Studio Code has similar thing like that. But it is not filterable.
Actually I have similar ideas when implementing and testing the recently added parent namespace nodes into the Navi Bar.
The tree structure user interface usually means ... ... lots of work :)
Thus I will keep this open and get my hands onto it, maybe when another long holiday comes...
Oh I understand that it will likely involve lots of work. Not a big fan of implementing Tree-UIs myself. I just wanted to share an idea so that maybe you can implement some of it in the future. Glad to know you had similar thoughts!
Your latest addition of displaying parent namespaces to the NaviBar and general functionality improvements you have done to the NaviBar recently suggested to me a possible, more holistic approach of using NaviBar as a kind of super-source-code navigator, which really shines with bigger code bases.
In particular 2 major areas stand out:
Area 1: Tree View instead of List View
The idea is basically to replace the current ListView/ListBox-like control that lists subitems (namespaces, types, etc.) linearly with a tree-like control. Most likely this feature makes sense only for parent namespace elements in the NaviBar (since the current type's sub elements (nested types, methods, members) are already listed in the list directly as part of a current file or other partial files).
The way it would work for Namespaces as well as for Types not defined in the currently opened document is basically that each such item (representing either a Namespace or a Type in the dropdown) would be turned into expandable tree item, which, when clicked would dynamically expand and show its members (other namespaces and types for namespaces, and nested types and members for types). These nested subitems, in turn may too be expandable if they have any logical subitems.
So for example, assuming we have
A.AB.TypeAB1.cs
opened and there exists a typeA.AC.TypeAC2.cs
, when a user clicks on theA
parent namespace node on the NaviBar, he would seeAB
andAC
namespaces in the dropdown. These should be rendered as expandable items since both of them are namespaces that contain types. So, when user expandsAC
namespace item, it would listTypeAC2
as a subitem, which, in turn, too can be expanded further to revealTypeAC2
's members.I have no idea how hard it is to turn a ListView into a dynamic TreeView like this, so I don't expect this be done anytime soon, but I thought I would share this idea. I find it would make code navigation / understanding even better!
Area 2: Tree Grid instead of Tree View
Expanding on the idea of a Tree above. Even better would be to make it into a Tree Grid, i.e. a tree with multiple, header-sortable, and perhaps even filterable columns.
The current design has a small toolbar at the top of every NaviBar dropdown where user can search by name and filter by item type (like classes vs structs vs enums). An alternative and a more flexible approach would be to merge that toolbar with a clickable Tree Grid / Grid header. Clicking on the header of a column would show basically 2 options: 1) sort by directions 2) filter (a menu with checkboxes for example that list all possible variants). So the idea is to make it very similar to how MS Access does it for example in its tables.
So, this way instead of having just one column (basically item name with syntax), there would be more columns, all of which could be sorted by / filtered by:
Final Thoughts
Thanks.
The text was updated successfully, but these errors were encountered: