I don't really understand the use case or requirements. In particular, existing Bokeh data sources are, to my mind anyway, fundamentally not hierarchical. So what exactly does it mean to adapt them into a collapsible (i.e. tree-style) layout? Alternatively are you proposing an entirely new data structure?
So for there to be any chance of movement on this, someone will have to put together a much more thorough proposal:
some write-ups of use cases where this would be useful and why
explicit proposed new Bokeh API / syntax that users will have
detailed descriptions of desired behaviours
example scripts that would demonstrate this feature, once implemented
@lgasnier are you able to work up a real proposal? If not we will have to close this as too underspecified.
My concrete use case is the following. I have an ecological status that depends on:
benthic invertebrate fauna
chemical and physico-chemical elements :
See screenshot below (sorry, example in french)
With this tree data structure, I made a Div widget. Now, I would like to add in the layout a plot of the data used to calculate the status of each element (for example, nitrogen vs time). A click on one element of this tree would update the figure. But Div is just a display widget and can’t have a callback to interact with such a plot.
When I saw the thread mentioned above, I thought DataTable could be the right widget for my use case with some enhancements. But I don’t know if it represents a lot of work ;-)
So below is what I came up with.
New attributes proposed to TableColumn class
accordion (boolean): if True, field must be a tuple which size is the number of levels in the tree. See example below. A branch has a tuple with None as last index or indices according to its level, Note that a child must have a parent i.e. if tuple[i] is None then tuple[j] must be None for j > i.
expand_field (string; optional): the name of the source field used to initiate the expanded/collapsed rows. The field must be a list of booleans. Default True for all rows. For the leaves of the tree, True or False doesn’t matter.
offset (pixels ? number of characters ?) to shift column content according to the tree level.
expand_mark and collapse_mark (character ? image ?)
If a column has children (ie, tuple[-1] is None), add a mark to manage accordion (to collapse/expand the rows of the datatable). To collapse children rows of a parent, these children rows would be filtered according to the tuple content of the column values.
Thanks for the additional details @lgasnier With that detail I can see that something like that might be possible and useful.
But I should be up front about expectations re: timing. This is probably not something that can be addressed by the small core team in the very near future. The DataTable is already one of the most complicated widgets, and it has several current regressions due to a lapse in our automated testing. We need to get it back in reasonable shape before adding more complexity to it. I am working on fixing our testing infra which is itself a large task, then going to get the current DataTable stable under test. The other thread of work now is a final clean up of layout. Those are the priorities for an upcoming 1.0 release. Since this issue describes a new feature without breaking API, it definitely won't come before the 1.0 which is a few months away.