[DateTimeWidget] add key_events and fix setting dates#13214
Conversation
| extra_callback = nil, | ||
| } | ||
|
|
||
| local IMPOSSIBLE_DATES = { |
There was a problem hiding this comment.
I don't believe they're impossible. That is, 31 April is automatically resolved to 1 May, and so forth.
There was a problem hiding this comment.
"impossible to happen in real life", nervous laughter... I know it's resolved, however, I believe that is not the ideal way of dealing with it. If I end up accidentally choosing the wrong date, and since the computer will just accept anything, I might end up with a completely wrong date. We should not expect everyone to double check the message on-screen afterwards. Example, I might choose to set the day first (31st) then want to select July but by accident choose June instead, now my date was set to 2025-07-01 (we're off by a whole month)... I didn't pay attention to the screen or pressed somewhere and that went away quickly, yada yada yada, all my dates are now wrong until sometime in future when I notice it and curse the heavens.
There was a problem hiding this comment.
Have no idea at this particular codepath, so maybe my suggestion isn't as easy to implement.
When I'm on the 30 of April I would expect that pressing the up arrow on the day would set the date to 01 May.
When I'm on the 31 of May I would expect that pressing up the arrow the month would set the date to 30 June.
That would solve the "invalid date, please try again" that the current PR enforces and sounds like an improvement for your usercase:
I know it's resolved, however, I believe that is not the ideal way of dealing with it. If I end up accidentally choosing the wrong date
Because you're accepting the date you're seeing on the screen and that cannot be wrong :)
Just my two cents. Current implementation works for me :)
There was a problem hiding this comment.
Have no idea at this particular codepath, so maybe my suggestion isn't as easy to implement.
When I'm on the 30 of April I would expect that pressing the up arrow on the day would set the date to 01 May.
When I'm on the 31 of May I would expect that pressing up the arrow the month would set the date to 30 June.
I think it should be surprisingly simple.
> t = os.time{year=2025, month=13, day=35}
> date = os.date("*t", t)
> print(date.year, date.month, date.day)
2026 2 4See https://www.lua.org/pil/22.1.html
Current implementation works for me :)
I recently referred to the behavior as convenient, even if I wasn't really referring to this particular use case. (There's time sync, which is much easier to use since it does it automatically.)
There was a problem hiding this comment.
under normal circumstances, i.e setting the date in year-month-day order, one should never even get to see things like the 30th of Feb, the system now will automatically cap you at 28 or 29 days accordingly (for feb, whatever the correct number of days for other months). In other words, if you start setting the date in a sensible manner you should never even get to have those edge cases.
however, we can can still trick the system by doing what I described in my previous reply, and that is where the big NO hits you in the face.
There was a problem hiding this comment.
What I'm saying is you can leave all the logic to the system.
If day > 28 or month > 12 parse it and adjust the display if necessary.
| { month = 11, day = 31 }, | ||
| } | ||
|
|
||
| function DateTimeWidget:isValidDate(year, month, day) |
There was a problem hiding this comment.
Reinventing the wheel.
| -- check if we're on the 29th February | ||
| if current_month == 2 and current_day == 29 then | ||
| -- check if the new year-value is a leap year | ||
| if value % 4 ~= 0 or (value % 100 == 0 and value % 400 ~= 0) then | ||
| -- change to 28th February |
There was a problem hiding this comment.
Shouldn't that also use the daysInMonth thing like on line 221? Looks good otherwise.
|
unrelated to this, do you know if a Sony model: PSR T1 can run KOReader? |
|
It you meant to write "PRS" (and not "PSR"), we may have had support for it until we removed the build because we couldn't keep building for it and it felt nobody was using it. |
|
We stopped building it nine months ago, but we don't know if it even worked on one of the devices before that. (It did work years ago of course.) |
|
someone is selling one of those, I guess I'll pass on it then. thanks! |
|
Nobody could ever reproduce the necessary changes to the system image ;). |
|
👀 |
what's new
info_textfor setting the date to clarify the date format.registerKeyEventsto handle different configurations based on the number of pickers.onDateTimeButtonPressedto process value changes for the widget components based on the direction of the spin. This method ensures that the correct widget is modified and updates the maximum days in a month dynamically.createLayoutmethod to includedate_monthanddate_yearproperties for the day widget to facilitate dynamic date validation.screenshots
this madness won't occur again ;), we can no longer select any fake dates.
before / after
depends on #13208
This change is