You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
We could use the MatrixData trait with type Box<dyn Any>, then downcast data when reading, somehow.
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.
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.)
The text was updated successfully, but these errors were encountered:
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.
KAS already supports:
List
: a row or column of widgetsGrid
: a "matrix" layout of widgets, supporting merged cellsListView
: a list of user-typed data (ListData
trait) with aDriver
creating/reading/writing temporary view-widgets over each data itemMatrixView
: likeListView
, but with grid layout and 2-dimensional data array (MatrixData
)Tables are a little bit different:
MatrixView
as an optional featureThe latter is trickier to support. Some suggestions:
MatrixData
trait with typeBox<dyn Any>
, then downcast data when reading, somehow.ListData
trait where the data type is a tuple representing a column, and construct one widget per row (likeexamples/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.ListData
trait with a tuple per row, but use a variant of theDriver
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
widgetand
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.)
The text was updated successfully, but these errors were encountered: