beeware
A more compact DateInput on GTK+ Backend
What is the problem or limitation you are having?
The GTK DateInput is different from all other DateInputs because it displays a larger calendar, rather than a compact line with the date; however, in some contexts one may except a short line displaying the date, such that the layout differences are not that large between platforms.
Describe the solution you'd like
Not clear right now. I'm not sure if any more compact solution from which the calendar displays in a dialog would feel non-native; investigation of date related apps on Linux is needed before we should make such a decision.
Describe alternatives you've considered
Status quo, users can if-condition to switch their interface to a button with a popup calendar for GTK only if needed; however I'm feeling that there's too large of a layout difference when it comes to date picking for Linux compared to other platforms.
Additional context
The latest PR adds a success story for an app which uses a TextInput to pick a date:
However, one may imagine DateInput being used there. That's where I got the inspiration for this issue, which may be totally flawed.
This might just be a stupid thing that I can't let go of...
Edit
Another use case of this would be if you have something like
Date: [DATEINPUT]
then the rather large DATEINPUT would be out of place compared to the label.
Agreed this is a weird/unfortunate discrepancy.
GTK doesn't have a native Time widget (AFAICT), so implementing TimeInput for GTK will likely involve a composite widget made up out of 2 text inputs (and a selection pulldown for AM/PM?). It may be appropriate to take the same approach for DateInput - replace the current GTKCalendar based implementation with a TextInput/Selection based composite. That would restore GTK to a more consistent appearance for date input display; and I don't think it would be that alien as an option. A popup-based approach as you suggest might also be an option - although it would require more implementation effort to make that work.
Another approach would be to separate the DateInput widget from the Calendar widget. This idea came up in conversations at EuroPython - someone wanted an explicit "visible calendar" widget on Android, because their app involved displaying dates in a way where having a visual calendar was more helpful than a single line 'text date'. However, this would likely require manually implementing a calendar widget on most platforms, as GTK is unusual in providing a true "calendar" widget.
@freakboy3742 Hmm... Maybe even a popup button that displays a calendar may be appropriate. All impls even in native apps are sorta ad-hoc, e.g. IIRC some even used 3 separate TextInputs for Day, Month, Year.
FWIW: calendar widget should be viable at least on desktop.
macOS: Style set to https://developer.apple.com/documentation/appkit/nsdatepicker/style/clockandcalendar?language=objc
iOS: ???
GTK: Gtk.Calendar
Winforms: https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.monthcalendar?view=windowsdesktop-9.0
Android: ???
@freakboy3742 Another question: Since API would be nearly identical as DateInput if we choose to implement calendar, would it make sense to add another 'mode' to DateInput? Like, call a function to switch to calendar and vice versa.
I can see how a boolean flag on a single widget would be one possible approach.
However, while the initial API would likely be identical, there's no guarantee that would be the case long term. I can imagine that we might eventually add controls to alter the display of a calendar, and those API controls wouldn't make any sense on a "simple" DateInput. Even in the initial implementation, the hinting characteristics of a "simple" and "full" date input would be different.
There's also the question of how to represent "partial support" in widget availability charts, and what to include in screenshot previews.
Lastly, it would mean introducing a property that can be set on construction, but not modified after construction. That's not a problem to implement, but it is a bit of an oddity.
On that basis, I think maintaining a separate widget for Calendar makes sense.
#3734 tracks a calendar proposal. Marking my calendar-related comments as off-topic.
I have info on all the native APIs of all platforms there, I've researched and found APIs for all of these, Calendar should be viable.