-
Notifications
You must be signed in to change notification settings - Fork 25
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
Disabled state: details #328
Comments
Important to the above is a question: what is the purpose of the disabled state anyway? I can imagine two related cases:
This prompts some questions:
Thus, we could possibly make this change:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Follows: #82
What actions are/should be possible for disabled widgets?
Before #323, no events were sent to disabled widgets; since then
Event::pass_when_disabled
is used to determine whether the event should be sent to disabled widgets (roughly speaking, input events are not sent while programmatic updates are).Active pointer/character/selection grabs cancelled— it's not clear that this is necessary;Lost*Focus
events are still sent to disabled widgetsPressEnd
if widget is disabled during a grab? Currently it's not.Due to the last point, it isn't clear that "do not send events" is the best way to implement disabled status.
Further note: the Gallery example now has its own
trait SetDisabled: Widget
used to disable panels inside aTabStack
widget. This feels a little wrong.Alternative: widgets implement their own disabled behaviour
This is a possibility, but probably not the right one (it results in a lot of boring, repetitive code that often won't be well tested):
fn set_disabled(bool)
toWidget
(which doesn't necessarily need to do anything, since disabled status can already be queried via theEventState
)A variant of this:
The text was updated successfully, but these errors were encountered: