-
Notifications
You must be signed in to change notification settings - Fork 780
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
Review the order in which a Mount
event is received and render
is called
#2914
Comments
See Textualize#2912 and Textualize#2914 for some context.
Have been caught out by this. Watching. Would be good to guarantee |
I've changed the label to bug, because it's basically considered idiomatic Textual at this point to initialise state inside your
|
FYI I have a way to repro a situation where import asyncio
from textual.app import App
from textual.widget import Widget
from textual.widgets import Button
class W(Widget):
DEFAULT_CSS = "W { height: 1; }"
def render(self):
return self.renderable
async def on_mount(self):
await asyncio.sleep(1)
self.renderable = "1234"
print("on mount")
class MyApp(App[None]):
def compose(self):
yield Button()
async def on_button_pressed(self):
self.mount(W())
if __name__ == "__main__":
MyApp().run() |
Progress being made. Widgets that haven't been mounted yet are being considered as "visible widgets" by the compositor too soon. E.g., changing Next up I'll figure out why unmounted widgets are making it to the compositor map so soon. |
It seems that the issue is in the way the compositor builds the map, which does not take into account which widgets have been mounted yet. Consider this tentative fix: class Compositor:
def _arrange_root(...) -> tuple[CompositorMap, set[Widget]]:
# ...
def add_widget(...) -> None:
if not widget._mounted_event.is_set(): # <-- new
return # <-- new This passes the full test suite and it takes care of the problem by preventing unmounted events from being considered when building the map. Another possible alternative would be to register widgets only after they're mounted but that doesn't sound correct. Another possibly possible alternative is to check if the “registering” process can be split into two in a way that makes sense:
I'll investigate if this third idea is a possibility. |
Just for the sake of completeness and explicitness, the exact issue is that the |
@rodrigogiraoserrao I guess we can close this? |
Yes, I forgot to link the PR to this issue. |
Don't forget to star the repository! Follow @textualizeio for Textual updates. |
Following on from #2912, we should look to see if we can guarantee that any freshly-mounted widget receives its
Mount
event before any call onrender
is made.The text was updated successfully, but these errors were encountered: