Should messages only post after user interaction?

[TomJGooding]

Should messages only post after user interaction? Currently there's some inconsistency between widgets which is causing confusion. See discussion #3400 for context.

@TomJGooding Based on previous conversations I've been involved in, I think the design choice for Textual is that it's those widgets [posting messages after a programmatic change] that are behaving "incorrectly" (for what it's worth my own personal taste is they're doing it correctly; but I don't get final say on that 😉).

I think you raise a good point and it's issue-worthy that one approach or another is settled on and applied across all widgets with such behaviour.

Also for what it's worth, I agree with Dave that those widgets are actually behaving correctly.

If some messages such as Select.Changed are different by design to only post after user interaction, I think this deserves a note in the docs at least.

[Edited to add more detail. Sorry, somehow I clearly messed up when originally creating this issue.]

[rodrigogiraoserrao]

I believe all messages should be posted at all the relevant times.
Mainly because it is easier for the user to opt-out of having a message posted using with self.prevent(...): than to opt-in by posting its own message(s).

Messages being posted when changes occur is also the most intuitive flow, while having to distinguish between a user clicking a TUI versus changes that are 100% programmatic is much harder.
As an example, consider the message Changed that some widgets have.
The message Changed has a very suggestive name (it's posted when the value of the widget changes) and the docstring will say the same thing.
So, if I assign to the reactive value, it is a reasonable thing to expect that message to be posted.
After all, I just changed the value!

Finally, distinguishing between changes that happened because of an action that a real user took on a running app versus changes that are 100% programmatic isn't that easy because all we see, and the only thing we can change, is code; so having to reason about why something started happening is an extra burden on the Textual user (the one writing apps).

[davep]

One caveat I'd make to the above, which I don't think is in opposition to anything above, more adding to it and increasing clarity: it should be 100% fine to prevent certain messages from bubbling up from compound widgets (consider how RadioSet handles changes while stopping the RadioButton messages).

Some thought about any initial Changed event might also need to be taken into account.

[TomJGooding]

Sorry to bump this issue, but I think the design choice for Textual messages is important and needs some clarification.

I missed #2500 from back in May when I created this issue, and there's been a number of other issues/discussions since.

@willmcgugan I think your input is needed here!

[rodrigogiraoserrao]

I personally feel like this is a wart we should get rid of ASAP.

Regardless of what is decided, we need to go through the widgets and make sure their messages adhere to the “standard” we decide on.

[willmcgugan]

@rodrigogiraoserrao I'm confused about what your position is. What is the wart that you want to get rid of?

My feeling is that we should always send messages, and use the prevent context manager to suppress messages we don't want. Otherwise it is going to be difficult to know if something was initiated by the "user" or the "developer".

[rodrigogiraoserrao]

The “wart” was the inconsistency because we weren't doing neither thing consistently (always post or always ignore messages initiated by the developer).

[rodrigogiraoserrao]

If it's settled that we want to always post messages and then the developer can prevent the ones it doesn't care about, I'll close this issue and open a new one specifically to track the task of going through the widgets and making sure we're doing this consistently.

[github-actions]

Don't forget to star the repository!

Follow @textualizeio for Textual updates.