beeware / beeware/toga

Use Travertino for Table and Tree Column Widths

Open
#4,238 3 comments 1 reaction 0 assignees View on GitHub
enhancement
Dominant language
Python
Stars
5.4k
Forks
827
Avg merge
15h 39m
Merged PRs (30d)
40

Description

### What is the problem or limitation you are having?

Currently we rely on the backend implementations to set sensible column widths in the Table and Tree widgets. However each backend behaves differently, and there is no common API that permits the developer to specify the widths of columns, either in absolute units, or as a proportion of available space.

### Describe the solution you'd like

Travertino's "pack" layout algorithm is exactly designed to handle the problem we are trying to solve with column widths: packing a collection of boxes into a larger space according to width specifications for the boxes. And with the introduction of `Column` objects, there is a natural place for the user to add the information.

The solution I'm proposing is that the `Column` objects grow a `style` attribute that acts similarly to the `style` of a `Widget`, but the width and flex are used to determine the widths of the columns. These would be used to compute the width of each column given the width of the Table or Tree widgets, and then these would be set directly on the native widget as hard-coded values. When the widget resizes, the values would be updated appropriately.

The other attributes of the style object could potentially be used for things like giving the default colors and fonts for the cells in the column. However some style attributes don't make sense in the context of column objects.

### Describe alternatives you've considered

A possibly simpler alternative is to have the `Column` objects grow `width` and `flex` attributes or something similar, or coming up with some other algorithm that is more precisely targeted on the problem of column widths, rather than using styles and a general-purpose algorithm like pack.

The status quo is also an option. Things work.

### Additional context

Giving users the ability to re-size columns potentially makes things more complex, the core problem being how to handle re-sizes of the widget.

I'm not yet familiar enough with the internals of toga/travertino layout to know (a) if this is reasonable, and (b) if it is, how best to implement it (eg. to columns become children of the table widget even though they aren't widgets?)

I suspect that we are going to want to have a `style` value for columns no matter what even if the sizing part is not used, for handling things like fonts and colours.

Related issues: #3390, #2191, #1066, #3760, #4109

Contributor guide

Open the contributing guide

Research direction

Review the Table and Tree widgets, the Column objects, and Travertino's pack layout algorithm to determine whether column sizing can use the existing layout model. Clarify how width and flex specifications should interact with widget resizing and whether columns should participate as layout children. Done should include a defined common sizing API and behavior for resized tables and trees.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.