Style Information in `AccessorColumns`

[corranwebster]

What is the problem or limitation you are having?

Assuming #4258 or something like it is merged into the codebase, or more generally if table and tree cells gain the ability to be styled based on data values, it would be good to provide a simple API to allow style information to be passed via ListSource/TreeSource and AccessorColumns in a similar way that icons are handled.

However it is done, it should be possible to specify the text alignment, text and background colors, and font attributes.

The end-goal is to have users be able to do something like:

Table(
    columns=['foo', 'bar'],
    data=[
        {
            'foo': (None, "item 1", {"color": RED}),
            'bar': (None, "3.14159", {"text_align": RIGHT}),
        },
        ...
    ]
)

or similar for simple tables and trees.

Describe the solution you'd like

The behaviour of the AccessorColumn should be enhanced so that the value it gets from the row can confer the style information, if it is structured correctly.

However, design is needed.

Following the example of the way icons can be specified, I would suggest that some of the following are worth considering:

1. just as if there is an icon attribute, if there is a text_align, color, background_color, etc attribute on the value, that is used for styling the cell.
2. just as if there is an icon attribute, if there is a style attribute it should hold a dictionary of style settings with keys like "text_align", "color", etc. and the values are used for styling the cell
3. just as if there is an icon attribute, if there is a style attribute it should hold a StyleT and the attributes of the style are used for styling the cell
4. if the value is a tuple, we allow the tuple to be a length other than 2, and the additional values hold style data, so you have values like (icon, text, text_align, color, background_color, ...) with None values meaning to use the default, and these are used to style the cell
5. if the value is a tuple, we allow the tuple to be a length 2 or 3 tuple, and if the 3rd value is present it holds a dictionary of style settings with keys like "text_align", "color", etc. and the values are used for styling the cell.
6. if the value is a tuple, we allow the tuple to be a length 2 or 3 tuple, and if the 3rd value is present it holds a StyleT are and the attributes of the style used for styling the cell.

These are mostly mutually compatible (although 4 isn't compatible with 5 or 6, most likely).

Possibility 4 has the issue of working out a natural order, and maybe supplying a convenience NamedTuple (called Cell perhaps) to facilitate creating the values, so you do something like:

data = [
    {
        "foo": Cell(text="item 1", color=RED),
        "bar": Cell(text="3.14159", text_align=RIGHT),
    },
    ...
]

Personally I don't think I'm in favour of 4, but I could be convinced; and all of the others seem reasonable.

Describe alternatives you've considered

Don't do anything, the additional complexity is may not be worth the benefit, and if a developer wants to have styling on AccessorColumn-based tables and trees, they should just subclass AccessorColumn.

Additional context

PR #4258 would provide most of the infrastructure: the additional work would all be on the AccessorColumn class.

Like #4258, this is aimed at data-based styling, not at integration with Travertino styles, for now.

[freakboy3742]

This ticket is entirely predicated on "#4258 is merged as is"... which seems premature; as noted on that ticket, I have some reservations about the design proposed there. I'm also a little hesitant about the idea of mixing data and style like this; I can certainly see how people might want to do this sort of thing, but I wonder if a better approach might fall out of a resolved design discussion on #4238.