Textualize / textual

The lean application framework for Python. Build sophisticated user interfaces with a simple Python API. Run your apps in the terminal and a web browser.
https://textual.textualize.io/
MIT License
25.22k stars 774 forks source link

[docs] Inherit documentation for some objects #3079

Open rodrigogiraoserrao opened 1 year ago

rodrigogiraoserrao commented 1 year ago

Things like the Checkbox API documentation are missing lots of information because they inherit most of their behaviour (from ToggleButton, 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

merriam commented 3 months 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?

davep commented 3 months ago

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.

merriam commented 3 months ago

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 makeDOMNode` 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.