[widget audit] toga.DateInput, toga.TimeInput

[freakboy3742]

Audit of the DateInput and TimeInput widgets.

Renames the widgets from Date/TimePicker to Date/TimeInput for consistency. The widget was previously undocumented, and is only currently implemented for Android and Windows, so the impact of this change should be minimal. A compatibility shim for the old name has been included.

Fixes #1962.

Audit checklist

• Core tests ported to pytest
• Core tests at 100% coverage
• Core docstrings complete, and in Sphinx format
• Documentation complete and consistently formatted
• cocoa backend at 100% coverage (not implemented)
• winforms backend at 100% coverage
• gtk backend at 100% coverage (not implemented)
• iOS backend at 100% coverage (not implemented)
• android backend at 100% coverage
• Widget support table updated
• Widget Issue backlog reviewed

[mhsmith]

Renames the widgets from Date/TimePicker to Date/TimeInput for consistency. The widget was previously undocumented, and is only currently implemented for Android and Windows, so the impact of this change should be minimal. A compatibility shim for the old name has been included.

For consistency with NumberInput, I've also renamed min_date and max_date to min_value and max_value, and similarly with the TimeInput. At some point we might want to do the same thing with the Slider, which is an outlier because it uses a combined range rather than separate min and max.

[freakboy3742]

For consistency with NumberInput, I've also renamed min_date and max_date to min_value and max_value, and similarly with the TimeInput.

Good catch - 100% agreed.

At some point we might want to do the same thing with the Slider, which is an outlier because it uses a combined range rather than separate min and max.

Also agreed.

It occurs to me that we should start logging specific tickets for the resolveable issues that we're finding as a result of this audit (e.g., styling of Selection on GTK, ActivityIndicator not implemented on Informs, etc). Prior to the audit, there wasn't a whole lot of value to having tickets for all the micro issues and missing platform features; now that we have coverage testing, we have a specific list of things that are missing, the platforms where they're missing, and a known contract that they should be adhering to. This sort of API inconsistency fits that pattern.

[mhsmith]

@freakboy3742: The Android testbed is hanging intermittently, so this isn't quite ready to merge, but it would be useful for you to review it now.

[freakboy3742]

Periodic freezing notwithstanding, this looks pretty good; I've flagged a couple of things we should probably raise in the user-facing notes for the widgets, plus one possible approach for a "soft" min/max on Android TimeInput.

[freakboy3742]

Are these values with a significance to Android? We should document why these dates in particular has been picked - both in the code, and in the user-facing widget notes as a functional limitation.

[mhsmith]

As discussed, I've changed the implementation to allow years between 1800 and 8999 on all platforms, and updated the documentation to match.

[freakboy3742]

Would it be worth doing a "soft" min/max? i.e., we have control over get_value(); if there's a min_value of 6AM, and the user picks 3AM, we could modify get_value() to return 6AM. It's not ideal UX, but it would at ensure the Android implementation doesn't return values that aren't invalid.

[freakboy3742]

Worth documenting these limits in the user-facing notes.

[mhsmith]

See above.

[mhsmith]

I've changed the min and max properties as follows:

• They always return an actual date or time rather than None.

• Consider changing the min/max from 10/20 to 30/40. Previously, to avoid a ValueError, you would need to update the max before the min. But when going from 30/40 to 10/20, you would have to set the min before the max. This would make it inconvenient to write code that changed the limits between arbitrary values.

  So instead of throwing a ValueError, I've changed it so the min can now clip the max and vice versa, with the property currently being set taking priority.

[mhsmith]

Ready to merge.

[freakboy3742]

👍