Disabled state: details

[dhardy]

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).

• Content displayed differently (usually "greyed out")
• Does not respond to mouse hover
• Not keyboard navigable
• Active pointer/character/selection grabs cancelled — it's not clear that this is necessary; Lost*Focus events are still sent to disabled widgets
• Send PressEnd if widget is disabled during a grab? Currently it's not.
• Allow text selection in disabled widgets? (This would imply sending mouse/keyboard events, thus the widget would be responsible for marking itself read-only instead of simply not delivering input events.)

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 a TabStack 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):

• Add fn set_disabled(bool) to Widget (which doesn't necessarily need to do anything, since disabled status can already be queried via the EventState)
• Widget event handlers are responsible for implementing disabled status

A variant of this:

• By default, widgets do not handle (most) events if disabled, but this behaviour may be overridden

[dhardy]

Important to the above is a question: what is the purpose of the disabled state anyway? I can imagine two related cases:

1. The widget is used for output only and not interactive. For this purpose, we have the dedicated read-only ScrollLabel, while EditBox and CheckBox have an editable property.
2. The widget is part of the UI design but not currently applicable (e.g. the "return date" when booking a one-way flight). For this purpose, the widget can be disabled, both preventing editing and visually de-focussing (but not completely hiding) the widget.

This prompts some questions:

• Why is editable a property of a few widgets while disabled is a property of all widgets? Well, only a few widgets appear to be both interactive by design and useful while read-only, while most widgets (potentially even labels) may be affected by the disabled property in some way. (Only a partial rationale.)
• Why can the disabled state be set recursively but read-only cannot? Again, a half-answer: it may be necessary to disable many widgets, but it's not usually necessary to set many to read-only mode.

Thus, we could possibly make this change:

• Make read-only a property of the EventState not the widget, like disabled currently is, except that widget event handlers must implement behaviour adjustments themselves