Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: