beeware / beeware/toga

Style Information in `AccessorColumns`

Open
#4,261 1 comment 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Python
Stars
5.4k
Forks
827
Avg merge
9h 45m
Merged PRs (30d)
58

Description

### 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:
``` python
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:
``` python
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.

Contributor guide

Open the contributing guide

Research direction

Start by reading the AccessorColumn class and the infrastructure proposed in PR #4258, then compare how icons are passed through ListSource and TreeSource. Done requires a settled API and implementation for data-driven text alignment, colors, and font attributes in AccessorColumn-based tables and trees.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.