No way to query a TabPane by id

[guystreeter]

When you create a TabPane specifying an id, and put it in a TabbedContent, textual creates a ContentTab with the same id. If you then try to query the TabPane by id, query_one raises WrongType because it finds the ContentTab.

from textual.app import App, ComposeResult
from textual.widgets import TabbedContent, TabPane


class Text(App):
    def compose(self) -> ComposeResult:
        with TabbedContent("foo"):
            yield TabPane("foo", id="foo")

    def on_mount(self):
        pane = self.query_one("#foo", TabPane)
        print(pane)


Text().run()

produces

WrongType: Query value is wrong type; expected <class 'textual.widgets._tabbed_content.TabPane'>, got <class 'textual.widgets._tabbed_content.ContentTab'>

It will be helpful if you run the following command and paste the results:

textual diagnose

Textual Diagnostics

Versions

Name	Value
Textual	0.41.0
Rich	13.6.0

Python

Name	Value
Version	3.12.0
Implementation	CPython
Compiler	GCC 13.2.1 20230918 (Red Hat 13.2.1-3)
Executable	/usr/bin/python3

Operating System

Name	Value
System	Linux
Release	6.5.11-300.fc39.x86_64
Version	#1 SMP PREEMPT_DYNAMIC Wed Nov 8 22:37:57 UTC 2023

Terminal

Name	Value
Terminal Application	Unknown
TERM	xterm-256color
COLORTERM	truecolor
FORCE_COLOR	Not set
NO_COLOR	Not set

Rich Console options

Name	Value
size	width=154, height=52
legacy_windows	False
min_width	1
max_width	154
is_terminal	True
encoding	utf-8
max_height	52
justify	None
overflow	None
no_wrap	False
highlight	None
markup	None
height	None

[davep]

If you then try to query the TabPane by id, query_one raises WrongType because it finds the ContentTab.

This is because you're making a pretty broad query here. In your case you want to be making a query for a TabPane whose ID is foo, so you would want to query for TabPane#foo.

[davep]

There are a lot of combinations that could be used, likely far more than makes sense to list all the permutations; but the guide to CSS does outline all the different things that can make up a selector, and also covers the general concept of combination.

[guystreeter]

Yes, but the documentation for query_one doesn't even say it uses CSS selectors, much less that any acceptable CSS selector can be used. It did not occur to me that "A selector" meant "A CSS selector".

Also, textual creating other classes that use my specified id, behind the scenes and undocumented, seems like a setup for confusion and error.

[davep]

The latter point is a good one and may benefit from some clarification. As for the documentation for query_one: the documentation is sort of written with the expectation that someone will read the tutorial and the guides first.

[guystreeter]

I did finally find one place that says "you can call query with a CSS selector". I had been searching for query_one, and I haven't found that kind of statement about it. I wish the documentation was more of a complete reference, but I understand that it's mostly auto-generated.
Thanks for your help.

[davep]

Just to be clear: the important parts of the documentation aren't auto-generated; and the parts that are auto-generated are written, by hand, by the developers, as carefully as possible (the generation is done from the docstrings in the code and part of our PR review process is to try and ensure they're as comprehensive as possible).

What I was trying to explain is that it's expected (and I think it's a reasonable expectation) that someone will have consumed the (hand-written) introduction, (hand-written) tutorial, and the (hand-written) guide. Having read those sections of the documentation, a developer working with Textual should be able to understand some of the terms that are used once you dive into the reference and the API. You're right that once you get into the reference and the API that some terms might go unexplained there, but a lot of effort has gone into trying to ensure that the tutorial and the guide will give all the grounding and background that's needed so the reader can comprehend the latter parts of the documentation.

Are the docs perfect? No; like Textual they're still a work in progress, there's more to do and improvements to be made; but do please try and appreciate how they're put together, how they're designed to be read, and also that they do seem to work very well for a lot of people.

Feedback is always welcome; I'd hope that pointers to the relevant parts of the documentation will always be received in the same spirit. :-)