Open kcpevey opened 5 years ago
Control over column width is absolutely something we could expose, in the matplotlib TablePlot
we also attempt to automatically scale the column width relative to the maximum of characters in each column, which might provide better defaults.
It seems like the total width of the total table is not related to cell size, drawing size, or the bokeh region (where the tools are). So it seems like it could have utilized some of this space better?
This is to do with the way widget sizing works in bokeh, according to the core bokeh developers this is a very hard problem because the widths and heights are determined by CSS, which means they cannot be computed ahead of time. Hopefully the ongoing layout rewrite will address this, if not there's probably not much we can do.
Control over column width is absolutely something we could expose, in the matplotlib TablePlot we also attempt to automatically scale the column width relative to the maximum of characters in each column, which might provide better defaults.
I'd be happy with automatic scaling to column width for now and exposing more control being left as an option for the future.
according to the core bokeh developers this is a very hard problem because the widths and heights are determined by CSS
I'm ok with the current state and like you mentioned, we can work with layouts as that is being developed.
This could be a request on bokeh
How is the width of the columns in the dynamic tables in the annotators chosen?
I have this:
![table2](https://user-images.githubusercontent.com/15659110/45887593-b59a0180-bd81-11e8-8ddf-1d976ece6bfa.PNG)
Some columns need to be wider because of contents (like datetime), some columns need to be wider because of labels (like Max_Wind_Speed), some columns could be smaller (like radius).
Related but different: It seems like the total width of the total table is not related to cell size, drawing size, or the bokeh region (where the tools are). So it seems like it could have utilized some of this space better?