Table planning: loose ends

[andlabs]

Table views will operate like GtkTreeView or NSTableView: you have a model with columns for raw data and a view with a series of columns, each containing cells that take those model columns and build the final view out of them.

There are a few things I'm not sure about when it comes to tables that I'll pose as an open question.

First, should table view and tree view be separate? They are on OS X, are not on GTK+, and might be on Windows.

Second, how should I permit the layout of each cell of the table? All cells in a column would have the same layout, but I really have two options here:

• Fixed: you can have ONE checkbox, ONE image, ONE text, ONE progress bar, etc. or any combination of the above (in a fixed order), and one background color for everything in a cell
• Variable: you can create complex but linear layouts of cell options, each pointing to different columns of your data model; this would be similar to uiBox, but with slightly different mechanics

The question is really about how much freedom I need to give; it might not affect the implementation on GTK+ or OS X too much, but it will for Windows.

Third, and speaking of Windows, I'm still not sure if I should just custom-draw a List View or use my own control for this. (I have my own, but I want to redesign it to use the variable cell renderer approach.) If I do take the custom draw approach, I wouldn't know how to handle accessibility...

[andlabs]

Yes, GTK+ assumes sorting the view means sorting the model, but for GTK+ you don't actually alter the model. Instead, there's a type called GtkTreeModelSort that implements sorting for you — you hand it your regular tree model, and it wraps around your tree model, effectively mapping row numbers between your model and whatever sort is currently being used. Then you pass that to the GtkTreeView. Of course, this means that with selections and other view accesses, you'll need to go through the GtkTreeModelSort to get your underlying model's actual row number.

There is a similar facility for filtering out rows provided by GtkTreeModelFilter.

Ideally libui should provide similar abstractions to avoid needing to explicitly sort and filter data yourself; I'm not sure how to provide sort or filter predicates on Windows or macOS (unless I did it with ohv and forgot).

[bcampbell]

Mainly for my own reference - a Raymond Chen blog post about some of the underlying ad-hocness in the windows treeview: Tree view check boxes: A sordid history

[bcampbell]

@andlabs: by the way, I've been a bit busy on other stuff, but I'd like to do a push on getting the table stuff merged in over the next couple of months. Do you have any specific things that you regard as "must-haves" that are still missing from the stuff I've been doing? Or things you'd definitely want changed? Or maybe it'd be better to keep the table stuff as a separate library for now? (I don't think there are any changes to the core libui. It all seems to apply fine on top of your utflib-and-attrstr branch).

[andlabs]

That's why I was using branches to begin with =P I want to review everything you've done up to the point I'm ready to push before I push anything, since I'm not sure what you have done since the last time I commented.

And yes, I'm following the treeview checkbox articles closely.

[bcampbell]

Cool - let me know if there's anything I can do to make reviewing easier.

The last couple of commits I made (a couple of months back) were:

11a98bfedb96293849b06f88b77e9cad79938db7 (add OSX support for iterating over currently-selected items) 0e566386595aaca9bd54ee93dedc2e029535283c (add OSX support for the onSelectionChanged callback)

This brings all three platforms up to par (barring the windows lack of support for non-text sub-widget parts).

The selection iteration stuff is probably the major thing you'd want to review - it's the biggest API addition. I've documented the functions in the header file with godoc-style comments.

The other API change is that uiNewTable now takes style flags. The only flag currently supported is MultiSelect, but there are a few others which would make sense (and which are required at creation time for some platforms).

Hope this is useful!

[jrgp]

Hi @andlabs do you have any update on this being merged into master? I'd love to use it in the go bindings (I'm working on a linux music player app in golang and the table would be for showing the song list/browser)

[andlabs]

No, but soon (next few days, perhaps?) I'll be done with utflib-and-attrstr as it currently stands and I'll start merging PRs afterward. This particular patch set will need to be reviewed, of course (just as all PRs do).

[bcampbell]

@jrgp: I did hack up some golang support for my table branch: https://github.com/bcampbell/ui/tree/table

If you decide to try it out, I'd love any feedback you have. It needs more people hammering on it to get the core API properly rounded out. And using the golang bindings will help exercise the underlying C api, so go nuts ;- )

My own use case for tables is pretty basic - I want to support columns of plain text (although I'd love hyperlink support), with good performance on datasets up to millions of rows. I don't need any other fancy stuff, so my work has been focused on those core features - and luckily, the crappy windows commctl table supports that. I figured it gets us up and running, and fancier things can be added once a better windows table control is available. Extra features would extend the libui API rather than change what's there already.

[andlabs]

Replaced with #310.