Skip to content
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

Change emit to post to self. #1738

Merged
merged 4 commits into from
Feb 8, 2023
Merged

Change emit to post to self. #1738

merged 4 commits into from
Feb 8, 2023

Conversation

rodrigogiraoserrao
Copy link
Contributor

The point of this PR is that it makes it simpler to subclass widgets because you can capture messages that would be sent by the parent and repurpose them.

E.g., in the app below, the subclass of Input no longer emits Input.Submitted events, but rather MyInput.MyMessage events.

Code
from textual.app import App, ComposeResult
from textual.message import Message
from textual.widgets import Input, TextLog


class MyInput(Input):
    class MyMessage(Message):
        pass

    def on_input_submitted(self, event: Input.Submitted):
        event.stop()
        self.emit_no_wait(self.MyMessage(self))


class MyApp(App[None]):
    def compose(self) -> ComposeResult:
        yield MyInput()
        yield TextLog()

    def on_input_submitted(self) -> None:
        self.query_one(TextLog).write("input")

    def on_my_input_my_message(self) -> None:
        self.query_one(TextLog).write("mymessage")


app = MyApp()


if __name__ == "__main__":
    app.run()

@rodrigogiraoserrao rodrigogiraoserrao requested review from willmcgugan, darrenburns and davep and removed request for willmcgugan and darrenburns February 7, 2023 18:06
@willmcgugan
Copy link
Collaborator

It occurs to me that emit and emit_no_wait are essentially the same as post_message and post_message_no_wait. Which is a strange state of affairs.

I'm wondering if there is a legitimate need for something which posts to a parent, or we just drop the concept altogether in favor of post_message.

@rodrigogiraoserrao
Copy link
Contributor Author

I'm wondering if there is a legitimate need for something which posts to a parent, or we just drop the concept altogether in favor of post_message.

In my mind, I thought that emit would make a message go up the DOM and that post would send it to a specific widget without bubbling, but now it seems that it is the message itself that either bubbles or not, and that has nothing to do with the method that is used?

@rodrigogiraoserrao
Copy link
Contributor Author

I also think it makes sense to have a shortcut for a widget to post a message to itself, but perhaps it'd be better named post_to_self instead of emit...

@willmcgugan
Copy link
Collaborator

But self.post_message already does post to self.

@rodrigogiraoserrao
Copy link
Contributor Author

But self.post_message already does post to self.

Yeah, you are right 🤦
In that case, to me, it makes sense to get rid of emit altogether (or of post_message if we prefer the name emit).
Let me know and I'll pull the trigger.

@willmcgugan
Copy link
Collaborator

Give it a go.

I feel sad to get rid of emit for some reason. But one method is simpler than 2.

@rodrigogiraoserrao
Copy link
Contributor Author

Give it a go.

I feel sad to get rid of emit for some reason. But one method is simpler than 2.

Done in bd719e0.

Copy link
Collaborator

@willmcgugan willmcgugan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one tiny error. Have you searched the entire code to make sure there aren't any emits hiding in docs or examples?

@rodrigogiraoserrao
Copy link
Contributor Author

rodrigogiraoserrao commented Feb 8, 2023

Have you searched the entire code to make sure there aren't any emits hiding in docs or examples?

Yes, I've searched the codebase and the documentation (and the examples therein).

@willmcgugan willmcgugan merged commit 1b050ea into main Feb 8, 2023
@willmcgugan willmcgugan deleted the emit-start-with-self branch February 8, 2023 11:37
davep added a commit to davep/textual that referenced this pull request Feb 8, 2023
Makes sense to update all the docs to reflect the work done in Textualize#1738 but I
feel it doesn't quite make sense to retrofit this into an old blog post --
especially if the code it is referring to was like that at the time and
likely still will be for a wee while after this gets republished.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants