Open rodrigogiraoserrao opened 1 year ago
In most objects, there is a small section Bases
which links to pages for which there are pages. For example, at https://textual.textualize.io/widgets/list_view/, he base of ListView
links to Vertical Scroll
which links to ScrollableContainer
.
So, the actual issues appear to be a lack of total documentation. That is, missing documentation for ToggleButton, no examples for many layouts, etc.
Nothing specific to be done here, just would be useful for better documentation.
Close?
So, the actual issues appear to be a lack of total documentation. That is, missing documentation for ToggleButton
The point here though is that ToggleButton is really an internal implementation detail, so it would be better if the child classes were fully documented without it needing to appear in the docs.
Sorry, I guess I don't understand.
Functionally, the only method from ToggleButton that is Toggle() which should not be exposed as it returns an internal class, and has not functionality beyond my_radio_button.value = not my_radio_button.value
.
What is missing, all through the documentation, are descriptions about styling rules, as in what is really available and what applies to each widget. It feels like there should be a rewrite of . As an evil thought, how about we make
DOMNode` css inspectors?
The current css_tree
could get a makeover, having one function returning a tree of dictionaries, and another converting it into a Rich Tree object. The documentation could also mention how to print that tree.
Additionally, I would like to see more a more complete version, including the rule and location that causes the value of each setting. That is, ... css['background'] = { value: "#24292F", rule: ".button #mogrify", source: "myapp.tcsss:23" }
Finally, I want a version that goes "up", giving rules for each parent going up as a way of diagnosing CSS errors.
In practice, the most I would seriously commit to is to write an example and documentation for css_tree
to make it useful to more people.
Things like the
Checkbox
API documentation are missing lots of information because they inherit most of their behaviour (fromToggleButton
, in this case). What is worse,ToggleButton
isn't even publicly documented.But even if it was, you'd have one level of indirection that is very easy to miss: you have to remember to check if a widget has a base class more specific than just
Widget
.I suspect for things like
Checkbox
/RadioButton
, and possibly other things, it would be helpful to inherit the documentation from the immediate base class.C.f. inherited members option in
mkdocstrings