Date picker
Fixes #233
Each backend has its own shortcomings:
- UIKitBackend has weird availability constraints on each picker style, doesn't support
hourMinuteAndSecond, and doesn't respect font color- Furthermore, UIDatePicker doesn't exist on tvOS
- AppKitBackend doesn't support the
wheelpicker style - WinUIBackend doesn't support
hourMinuteAndSecond, doesn't respect font color, and doesn't respectenvironment.timeZone(instead always using the current time zone) - GtkBackend only supports the
graphicalpicker style, doesn't respectenvironment.timeZone(instead always using UTC), and only supports picking the date, not the time - Gtk3Backend is unimplemented as I have no way to test it.
The thought just occurred to me to observe NSSystemTimeZoneDidChange to properly redraw views that use @Environment(\.timeZone), but I'm unsure how that would work, and regardless I don't see an equivalent for the calendar.
There’s a backend method called setEnvironmentChangeHandler or something like that. That’s where we currently observe system theme changes and would be where timezone observation should live as well.
Right, I'll go see if I can get that to work in UIKitBackend and AppKitBackend first, and then maybe the other backends. I don't think it'll necessarily work on Linux though
Marking this as draft because UIDatePicker (at least on iOS 17) completely misbehaves if the user changes the time zone in settings
I think I've gone through and closed all of the review comments that have been addressed and commented on ones that I have more questions about.
Regarding the GtkBackend TimePicker implementation: when I originally reviewed it I didn't realise that it's unused. If you'd like, feel free to turn my current comments on it into todo comments and document clearly that the class is neither ready nor used, and I'd count those comments as resolved. I more just want to avoid another contributor coming along and trying to use it assuming that it's meant to work properly in its current form.
I think you'll have to run ./generate.sh && ./format_and_lint.sh to fix those Gtk build issues. I changed some things about the generation
Now that the DatePicker example is relatively simple, I reckon it could make sense to merge it into ControlsExample.
Done, and added a #if so that it can still run in Gtk3Backend (which doesn't implement pickers).
I've just been testing out the ControlsExample on my various machines, and noticed that the GtkBackend really spams the time picker not implemented warning. It might be worth updating it to only log that message the first time it's triggered. I believe that one of the other backends has a mechanism to do that already, maybe UIKitBackend from some of Mia's changes?
When I click a day in the GtkBackend Calendar picker, it selects the day prior for some reason 🤔
And when I click 'reset date to now', the focus ring stays on the date that I previously selected, rather than the programatically selected date. Maybe that's just a Gtk thing though?
I'll test locally while waiting for CI, then merge if all goes well.
Damn, merging in the changes from main caused WinUIBackend compilation to fail. It appears to be because I moved the implementation of naturalSize to a static method for convenience when implementing WinUIElementRepresentable. This patch fixes things for me;
I also removed the picker's label because it was line wrapping and causing the date picker to be really tall with no visible reason when the window was skinny enough. I tried making the label fixedSize but for some reason that did nothing.
And while testing on Windows I found that the graphical calendar view lets you unselect your selection without selecting anything else. I think in that case we should just programatically reselect the selected day again.
Will merge once CI finishes (it got re-triggered because I had to resolve a merge conflict)