Date Picker

[willmcgugan]

We need a nice date picker.

I see it working in a similar manner to select. See how browsers do it for inspiration.

Discuss design with @willmcgugan before attempting.

We will also need a complimentary time picker. I suspect we should tackle that after the date picker.

[TomJGooding]

When I think of a typical "date picker", this includes a text input and a calendar view which opens after clicking an icon.

Perhaps DatePicker should be a standalone widget that is the calender view, that can be used with a new DateField widget that opens the calendar view on a new layer?

[davep]

I 100% second the idea of it being a two-parter; I can absolutely envisage wanting the calendar as an always-there widget in some application, as opposed to a drop-down.

[TomJGooding]

Several months ago now I actually had a play at implementing a date picker. It is very rough and doesn't seem to work with newer Textual versions, but here's a demo:

[davep]

Yay #team-iso-8601-for-life 👍

[darrenburns]

Agree with keeping them distinct.

I also agree that it's useful to be able to type the date into the input too rather than having to navigate a widget, particularly if I'm selecting a date long in the past. I don't want to scroll through a Select to choose a year - this is actually another good use case for the ability to type to jump to an option in a Select.

[rodrigogiraoserrao]

Dropping my two cents, which appear to be aligned with Darren's last remark: I always want to be able to type.
Regardless of how the days/months/years are presented as choices, I want to be able to type the date I want (possibly in separate fields).

[TomJGooding]

I'd like to have a stab at adding this DatePicker, if everyone agrees on the calendar design?

But I'm afraid I'd need some guidance, as this would be a complex widget! Obviously I want to be a help rather than a hindrance, so let me know if you would welcome a PR.

[davep]

@TomJGooding Sorry, did mean to get back to you on this. This sounds like a good plan to us. In the first instance, do you want to give a longer proposal for how you want to approach this? If you are keen and happy to this this on and take it through to a full PR (with our help where needed, of course -- I'm happy to help here, in an actual PR, on Discord, even on an actual call 😱), we're happy to do that.

Let me know if you're still interested and I'll assign the issue to you.

[TomJGooding]

Thanks Dave, no problem I understand you have a lot going on at the moment!

I think everyone is in agreement that the datepicker calendar view should be a distinct widget, so this would also need a seperate widget to allow typing the date? Here's a quick sketch of how I envisage this:

DatePicker

This would be a compound widget consisting of:

• Buttons to navigate previous/next month
• Label to show current month*
• Buttons to navigate previous/next year
• Label to show current year*
• A DataTable to display the calendar for the month

I'm not sure if this should also include something to display a formatted date, similar to my example above?

*Or perhaps these labels could be buttons, which when clicked replaces the calendar with a new table to select the desired month or year?

DatePickerInput (widget name TBD!)

This would be a compound widget consisting of:

• Input to type the date (I'm afraid I'd need some advice on date format masking)
• Button which when clicked will open the DatePicker calendar view
• DatePicker on an overlay (similar to the Select widget)

Initial Questions

I'm sure I will need some guidance once I start looking at this in more detail, but here's a few initial questions I have:

• What should the type of DatePicker value be?
• Would you consider a new dependency for ease of relative date calculations (e.g. python-dateutil)?
• Should messages bubble up from the compound widgets?

[Edit: I've also realised that the date input might overlap with #3508?]

[davep]

A DataTable to display the calendar for the month

I wonder about the idea of using DataTable for this. If I were to tackle this I think I'd chiefly break it down as you've done here, but with one extra level.

So, at the most atomic level: a month calendar widget, likely built first as a calendar renderable (some other widgets in Textual are renderables at their core), with the widget part being the wrapper that displays that renderable and provides an API for navigation and update¹.

Then the compound widget you mention, which has all of the extra controls for easier navigation

And then, finally, the full picker input widget.

I would suspect that getting the API interface for that lowest-level widget, that wraps the renderable, is key and then everything else will follow on; the idea here being that the lower-levels will provide flexible APIs that allow building the higher levels, but which also let devs build their own date input systems too by taking the lower-level parts and gluing them together in different ways.

I'd also suggest we approach this with distinct PRs. So how about we kick this off with that renderable and go from there (perhaps the renderable plus lowest-level widget combo; as I can also see that the widget and renderable will each inform the other's design to start with)?

As for another dependency, I would have hoped that the date calculations would be doable with core Python code. Perhaps the calendar module will be helpful here?

Footnotes

1. Some thought might need to be given to how this handles size within a layout -- does it have a minimum dimension, or fixed, etc? ↩

[TomJGooding]

Thanks, I appreciate your advice on how to tackle this!

My idea of using the DataTable for the calendar was just to save having to reinvent the wheel in terms of rows/columns and the cell (i.e. day) hovered/highlighted/selected.

I'm happy to look at starting from a lower level though, if you think that is the better approach.