"List" ListBoxModel?


I may have answered my own question in the process of asking it here, but as a sanity check.

I have a component which is very much the same in style and behavior as your classic windows explorer with a tree (of containers) on the left and a list (of objects in the container) on the right. And, like windows explorer, can show additional information in custom columns for special types of objects (files, audio files, image files, etc.). The JUCE TreeView and ListBox components do a lot of the work out of the box for a “Detail” view, where each object has it’s own row and shows details about the object in specified columns. However, I could not find anything that would readily accommodate a typical “List” style view, where each object occupies a “cell” rather than a row, and the grid (rows*columns) change as the component is resize… am I missing something?

Certainly creating such a component isn’t rocket science, but consider that for my purposes is that “nested” (for lack of a better word) tableViews actually make sense here, for example:

_____________________________________________________________________ |______column_1________|_______column_2_______|_____column_3_________| | icon | id | filename | icon | id | filename | icon | id | filename | | icon | id | filename | icon | id | filename | icon | id | filename | | icon | id | filename | icon | id | filename | icon | id | filename |

…given that which “sub”-columns are shown are determined by the object type, or defined by the GUI designer via xml, or whatever… though in a “List” view the column headers would not be visible or re-sizable by the user.

I’m almost embarrassed to admit that in a rush to get this done I thought I might simply do just that; “nest” several tableModels inside of one component, but I don’t like the wackiness that would inevitably ensue sharing one dataset with multiple table components.

At this point I think I’m just going to create a custom model component which actually handles both modes as a setting/toggle, and handles rendering and selection depending on the current mode… because otherwise the functionality is ultimately the same.

For example, in “List” mode, core differences would be:

  • populating the cells when loading the data would be handled differently of course, and would change depending on the size of the component.
  • selection is cell based (or subset of columns, which could be nested in a “cell” component, as demonstrated above) rather than an entire row.

thoughts, suggestions, existing code welcome :wink: