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]

One of the most frequent requests I got when I first added tables to package ui was background color manipoulation

• Windows: entire row, custom draw
• GTK+: per-cell; not sure if there's an alternate way (TODO)
• OS X: per-row (cells have spacing and other stuff so doing that won't look good)

So what do we do here?

[kainjow]

For NSTableView there is setIntercellSpacing:

[andlabs]

That intercell spacing is not what I am referring to. I am referring to the necessary spacing required for alignment purposes.

[andlabs]

Okay, GTK+ only has per-cell backgrounds. So for background colors I'll provide something like

void uiTableSetBackgroundRowModelColumn(uiTable *t, int colNumber);

and that will provide the row color for the background.

That still leaves open the question of whether I should make a tree as part of this or separate — which will block development, so I need a consensus in the next 24 hours — and whether I use the Windows API list view, which can wait.

[andlabs]

Leaning toward just having uiTree like GTK+ does and treating the separation between treeview and tableview as an implementation detail. This will reduce the amount of code libui has in it, but makes the simpler table case slightly more complex to work with.

[HalosGhost]

Is there any chance you can link to docs or some really basic sample code / screenshots to illustrate the differences? I've been excited for table views for a little bit now, so I think there is a solid chance I will have an opinion, but I do not feel I have a solid enough grasp of the trade-off here to offer anything helpful.

[andlabs]

Sorry, which trade off do you refer to?

[HalosGhost]

The trade-offs between treating trees and tables separately or treating them as the same thing (the choice you are asking people to weigh in on).

I am not clear on what the benefits and negatives of each option are.

[andlabs]

Facts: trees and tables have the same basic UI: you have multiple columns and rows of data. The only difference is that a tree can have expanding data

Pros: keeps libui smaller, gets rid of code reuse in libui, gives us two birds with one stone, and a tree model is flexible enough to double as a table model

Cons: slightly more complex to work with in the case of non-tree tables; might need flags to treat tables specially visually(? windows only?), will REQUIRE a custom control or complicated custom draw on Windows

[HalosGhost]

In that case, I think it probably makes more sense, at least for now, to keep libui simpler and let the extra needed complexity be handled when it's necessary.

[andlabs]

So you vote for having a combined widget? Or not?

[HalosGhost]

Combined widget; sorry that wasn't clear.

[andlabs]

Another issue that just came up is that I can't seem to find a way to ensure that a NSTableView is fully distinguishable from a NSOutlineView. Other than that unifying might work.

We'll see how I implement this. I'll start now. Thanks!

[ctoth]

For the sake of accessibility I really favor separate controls and using native controls on each platform. On Windows making a treeview/listview hybrid accessible would require some form of UIA.
Not sure if you've already started the implementation here, sorry I missed this when it was open.