Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tables and aligned menus #297

Open
dhardy opened this issue Mar 14, 2022 · 2 comments
Open

Tables and aligned menus #297

dhardy opened this issue Mar 14, 2022 · 2 comments

Comments

@dhardy
Copy link
Collaborator

dhardy commented Mar 14, 2022

KAS already supports:

  • List: a row or column of widgets
  • Grid: a "matrix" layout of widgets, supporting merged cells
  • ListView: a list of user-typed data (ListData trait) with a Driver creating/reading/writing temporary view-widgets over each data item
  • MatrixView: like ListView, but with grid layout and 2-dimensional data array (MatrixData)

Tables are a little bit different:

  • rows and columns should support titles; this could be added to MatrixView as an optional feature
  • each column should have its own data type

The latter is trickier to support. Some suggestions:

  1. We could make the data trait and view widget specific to the number of columns, allowing a type for each column. This is the simplest to implement, but then we need many traits and widgets.
  2. We could use the MatrixData trait with type Box<dyn Any>, then downcast data when reading, somehow.
  3. We could use the ListData trait where the data type is a tuple representing a column, and construct one widget per row (like examples/data-list-view.rs), but then we need some hacks to ensure that columns and titles get aligned ("interior alignment", a complex feature), and to allow per-element selection.
  4. Again, we could use the ListData trait with a tuple per row, but use a variant of the Driver trait which either operates on a list (whole row) of widgets at once or uses a column-index. Like (2) we would need to downcast view-widgets to read/write, but at least this option avoids having to downcast data.

The last option appears the best, but still needs a specific TableView widget
and TableDriver trait.


Why this applies to menus: they are essentially tables; e.g. KDE's menus have columns for a checkbox, icon, label, shortcut, and sub-menu indicator. (Or they could just be a row with label, filler, and extra content.)

@dhardy
Copy link
Collaborator Author

dhardy commented Mar 14, 2022

Additional features:

  • Odd/even row highlighting: pass the row number to the theme.
  • Trees: this can just be a column to show + / marks and a row-filter (so long as we don't need to animate the transition).
  • Visual column/row dividers: just a border of theme-specified size. If this is simply drawn as lines/rects then drawing is simple, otherwise row/column intersections might be complex — but dividing lines should be small, so that's an unnecessary detail. Potentially selection boxes can be drawn on top.

@dhardy
Copy link
Collaborator Author

dhardy commented Apr 25, 2022

Menu item alignment was done in #305.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant