0.1.6 — form, field, and validation fixes

Fixed

• tristate works on a checkbox form editor. 0.1.5 fixed bs.Checkbox(tristate=True) itself, but a checkbox built by a Form (or by
  DataTable's add/edit dialog) still started unchecked: the form supplied an explicit value=False that overrode the indeterminate default. (#358)
• editor_options may set any of the editor's public keyword arguments. Naming one the form also fills — label, options, or a boolean editor's caption — raised TypeError: got multiple values for keyword argument. Those options now override the form's default instead of colliding with it. A value option seeds the editor only when the form's data carries nothing for that key. (#358)
• A falsy value no longer disappears from a text field. bs.TextField, bs.PasswordField, and bs.PathField tested the initial value for
  truthiness, so value=0 rendered an empty field — and in a Form, the blank was written back over the record's value.
• A form no longer changes the type of the data it was given. Values that are not text — a Decimal, a date — keep their type in form.data instead of being converted to strings at construction.
• Option dicts aimed at a built widget no longer collide with the framework's own arguments. The same defect appeared in
  MenuButton(menu_options=), ButtonGroup.add() / add_all(), RadioGroup.add() / ToggleGroup.add(), and Toolbar / StatusBar
add_widget(). In each, your options now win; the few keys a widget must own — where it is parented, how it tracks its selection, the callback that emits its events — raise a clear error naming what to use instead.
• A ButtonGroup button given both a caption and an icon renders as both. Supplying the caption as text produced an icon-only button with its label crammed into zero padding.
• A required field with a placeholder no longer passes validation while empty. A field showing only its placeholder was treated as though the hint had been typed, so required reported it valid — and a form with an untouched required field validated and submitted.
• text no longer reports the placeholder as content. A field showing only its placeholder returned the hint from text while value reported empty; the two now agree on whether the field holds anything.
• required survives an unrecognized editor= name. An editor name the form does not know falls back to a text field, but the required rule was dropped on the way, so a misspelled editor silently let an empty field submit. (#366)
• A searchable Select no longer changes its value when you just look. Opening the drop-down and dismissing it without typing or choosing anything replaced the field's value with the first option in the list. (#355)
• Select validation rules run against the selected value, not its label. On a decoupled option list — where an option displays 'United States' and stores 'US' — every rule saw the label, so a rule checking the value rejected valid selections. (#355)
• A Decimal value now respects value_format. It matched none of the formatter's numeric branches, so the format was silently ignored: a currency field seeded with a Decimal displayed the raw number and only started formatting once you edited it. Decimal is handed to the formatter as-is rather than converted, so a value keeps the precision it was given.

Added

• Select.validate() — run a select's validation rules on demand, matching the other field widgets. add_validation_rule already pointed at it. (#355)

Changed

• A format rule no longer rejects an empty field. email, pattern, and stringLength describe what a value must look like, not that one must be present, so they now pass on an empty field — matching range, which already behaved this way. Previously a field with no required= reported an error while untouched and Form.validate() refused to submit, leaving no way forward but typing into a field the form called optional. If you used a format rule as a presence check — stringLength(min=1), or a pattern that cannot match the empty string — add required to keep that behavior. compare and custom are unaffected; both still run on an empty value. (#366)
• A Select no longer rejects a value that is not in its option list. Opening an editor on a stored record whose option had since been retired raised ValueError: '…' is not one of the options — in a Form, and in DataTable's add/edit dialog, on ordinary data drift. A later programmatic write of the same value was silently dropped instead, so one value produced two different wrong answers. Such a value is now displayed as given, reads back with its own type, and is not added to the list, so a user cannot pick it. Use a 'custom' validation rule to report one. SelectButton, which maps a value to an option's label and has no text entry, still rejects. (#355)

What's Changed

• fix(form): tristate checkbox editor, editor_options collisions, falsy and typed values by @israel-dryer in #362
• fix(widgets): option dicts no longer collide with framework kwargs by @israel-dryer in #363
• fix(fields): a visible placeholder no longer counts as content by @israel-dryer in #364
• chore(tests): remove the legacy tests/features visual scripts by @israel-dryer in #365
• fix(validation): an empty field is not a malformed one by @israel-dryer in #367
• fix(select): a retired value displays instead of crashing the editor by @israel-dryer in #368
• docs: drop the Qt licensing line from the homepage blurb by @israel-dryer in #370
• fix(i18n): a Decimal value respects value_format by @israel-dryer in #371

Full Changelog: v0.1.5...v0.1.6