4 ms·

As I always do when yet another UI option comes along, I went looking for a hierarchical "tree" view widget in the documentation. Could not find it.

bismuthcrystal 4y ago
What are the implications, good or bad, of such absence?
- analog31 4y ago
  Not the parent, but a tree view is convenient for an app that has a lot of settings. For instance you can take a dictionary of settings and create a tree view with the same structure. If a setting gets added later, you don't need to rearrange the GUI, it rearranges itself. I've seen this kind of GUI in programs that manage complicated hardware such as scientific instrumentation.
- bsder 4y ago
  It's often a bad implication. The reason is that Treeview is where a lot of "rubber meets the road". It scrolls. It has icons that likely change state. It has active widgets. It may have a LOT of widgets and be a good test of performance. It has text and all of the idiocy that entails. It may or may not have selection. It has a connection to backing data. So, you get a nice microcosm of how you should plumb together the components of the UI toolkit if you look at the Treeview implementation. However, I would like to provide the contrarian position, as well. I find that far too many people use Treeview as a substitute for actual design. I often find that the TreeView really should be something else--a config file, a table interface (table interfaces are really underused in GUI design given how many of your users are wedded to Excel for business things), etc. Everything doesn't need to be pointy-clicky and often throwing things out improves your GUI. Treeviews tend to be the laziest of options--and, as we all know, programmers are very lazy.
Waterluvian 4y ago
I look for a sortable, filterable, selectable table. Like anything coming close to AntD’s table tells me that it’s serious business.

bismuthcrystal 4y ago

What are the implications, good or bad, of such absence?

analog31 4y ago
Not the parent, but a tree view is convenient for an app that has a lot of settings. For instance you can take a dictionary of settings and create a tree view with the same structure. If a setting gets added later, you don't need to rearrange the GUI, it rearranges itself. I've seen this kind of GUI in programs that manage complicated hardware such as scientific instrumentation.
bsder 4y ago
It's often a bad implication. The reason is that Treeview is where a lot of "rubber meets the road". It scrolls. It has icons that likely change state. It has active widgets. It may have a LOT of widgets and be a good test of performance. It has text and all of the idiocy that entails. It may or may not have selection. It has a connection to backing data. So, you get a nice microcosm of how you should plumb together the components of the UI toolkit if you look at the Treeview implementation. However, I would like to provide the contrarian position, as well. I find that far too many people use Treeview as a substitute for actual design. I often find that the TreeView really should be something else--a config file, a table interface (table interfaces are really underused in GUI design given how many of your users are wedded to Excel for business things), etc. Everything doesn't need to be pointy-clicky and often throwing things out improves your GUI. Treeviews tend to be the laziest of options--and, as we all know, programmers are very lazy.

Waterluvian 4y ago

I look for a sortable, filterable, selectable table. Like anything coming close to AntD’s table tells me that it’s serious business.