On 06/20/2016 04:19 AM, captaindet wrote:

You would have to implement some of the selection logic your self:
http://www.gtkforums.com/viewtopic.php?p=7354

thanks mike. so there is a workaround if i ever get that far with the
TreeView approach.

so it really seems to be the worst case scenario: i'll have to roll my
own (lightweight) spreadsheet. as in figuring out how many rows/columns
fit in the current widget space, arrange them (probably as grid of
selectable labels), manage my own scrollbars, manually change the data
on display in response to the scroll position...just to display a simple
data matrix. this sucks big time :(

You might want to look at a custom tree model for that case:
https://github.com/gtkd-developers/GtkD/tree/master/demos/gtkD/DemoCustomList

The demo only implements a simple list stored in an internal array.
But the TreeView only queries the visible rows, so that would hopefully
help with the performance. Additionally the data to be displayed can be
queried from where it is actually stored instead of building a separate
list beforehand.

interesting, i did not know a CellRendererText can display
numbers/integers directly.

and as you pointed out, tweaking this demo example could allow me to use
my raw data directly as input model for TreeView. this is not the time
sink, but would save some memory.

i don't understand, though, how this example helps to build my own
lightweight spreadsheet. it also uses a ScrolledWindow to reduce the
view on the model to what the current window offers - same as i did in
my testing.

in the meantime i have narrowed down the main problem of TreeView a bit
more. as the following example shows it is the mere creation of columns
that is of glacial speed, even if there is only one row and no data
model involved...
am i doing something fundamentally wrong here?
is there a trick to speed things up?
is this so slow in C/GTK as well?

I would reuse the Renderer, but other than that i don't see anything wrong.