0.3.1 — Dialog keyboard and modality

Fixed

• Pressing Enter in a dialog's multi-line field no longer submits the dialog. A dialog binds Enter so its default button can be pressed from an input field — which is what lets ask_string() be finished from the keyboard — and that binding stood down only for buttons. A TextArea answers Enter too, by inserting a newline, so the newline went in and the dialog closed on top of it: you were typing a paragraph and the dialog shut under you. Enter is now treated as text wherever it means text, and as a command everywhere else, so a TextArea or CodeEditor in a dialog body behaves the way it does anywhere else. A read-only one is unaffected: nothing there consumes the key, so Enter still presses the default button. The keypad's Enter key is handled on the same terms rather than assumed to match the main one: on the systems that report it separately, a multi-line field does not answer it at all, so it presses the default button rather than doing nothing at all. (#441)

• A dialog no longer loses its modality when a second dialog closes on top of it. The inner dialog took over the block on the rest of the app and then released it entirely when it closed, instead of handing it back. The outer dialog stayed on screen and still blocked the code that opened it, while you could click straight past it into the main window and drive the app underneath — modal in appearance only. This was reachable from ordinary code: any dialog button command that shows an alert, a confirmation, or a second dialog. Nesting now restores the previous dialog's modality at every depth, and closing the outermost one leaves nothing blocked. A window opened with modal="app" keeps the wider block it was created with, rather than coming back narrowed to this application alone. (#440)

• A dialog's default button now actually receives keyboard focus. It is documented as focused and triggered by Enter, but only the second half was true: the request was made while the window was still hidden, where it is silently ignored, so a dialog opened with nothing focused. Keyboard users got no focus ring and a Tab order that started from nowhere. The same defect meant the prompts that put you straight into a field — ask_string(), ask_integer(), ask_float() and ask_item() — did not focus their input either, so you could not type into one without clicking it first; those now focus their field, which takes precedence over the default button. ask_date() is unchanged, having no field to focus: its calendar still opens with focus on the window itself. (#439)

• The error raised for an outdated layout option now names options that exist. Passing fill=, expand=, anchor=, sticky= or side= to a child of any layout container correctly raises, but the message recommended align_self= and justify_self=, which were renamed before release and never shipped. Following the advice produced a second, lower-level error naming an option you had never written. The message now names real options, and which ones it names depends on how the container places the child. A Row or Column child is pointed at grow= for claiming leftover space along the stacking axis and horizontal=/vertical= for aligning or stretching across it. A grid cell — a Grid child, a page or a pane, or a child of any container built with layout="grid" — is pointed at horizontal=/vertical= and at weighting the row or column on the container, because grow= is not honored there: recommending it would have replaced advice that raised with advice that quietly did nothing. Both forms list the values each option takes. (#426)

What's Changed

• 0.3.1 — Dialog keyboard and modality (#426, #439, #440, #441) by @israel-dryer in #448

Full Changelog: v0.3.0...v0.3.1