qt_quick: dateTimeInput has no calendar/date-picker widget, just a formatted text field #1024

Activity

1. Yaraslaut commented on Oct 21, 2026

   

   Yaraslaut

   on Oct 21, 2026

   MemberAuthor

   More actions

   Additional finding from trying to adopt dateTimeInput for a plain string-typed "YYYY-MM-DD" draft field (LicenceServer's seat/feature dates, stored as std::string, not a timestamp type): it's not a drop-in replacement for textInput even setting the missing-picker issue aside.

   include/morph/ui/interpreter.hpp (~line 6061-6084), the dateTimeInput document-node handler:

   spec.value = slotProp<std::optional<time::Timestamp>>([element]() -> std::optional<time::Timestamp> {
       time::DateTime const* const instant = element->draft.get().asTimestamp();
       return instant == nullptr ? std::nullopt : std::optional<time::Timestamp>{time::Timestamp{*instant}};
   });

   The bound value must be (or convert to) a time::Timestamp-shaped value via asTimestamp(); a plain string draft value that isn't already in that internal timestamp representation reads back as nullopt, so the field never displays what was typed and never round-trips through onCommit/onChange the way textInput does for the same kind of string field. Confirmed by swapping a working textInput-backed "YYYY-MM-DD" field to dateTimeInput with no other change: client.type(...) + reading the value back afterward returned empty every time (both via the GUI automation driver and by eye).

   This means an app with dates modeled as plain ISO date strings (a common, reasonable choice, especially for apps with pre-existing string-based persistence) cannot use dateTimeInput at all today, calendar widget aside — it would first need to migrate its draft/value model to whatever time::Timestamp/asTimestamp() expects. Worth covering explicitly in the spec decision this issue asks for in its Scope section: either dateTimeInput should also accept a plain ISO date/datetime string value (coercing it, the way other inputs coalesce loosely-typed drafts), or the docs should say plainly that a string-backed date field must convert to morph's timestamp type first, with an example of how.
2. Yaraslaut commented on Oct 22, 2026

   

   Yaraslaut

   on Oct 22, 2026

   MemberAuthor

   More actions

   Confirmed the open question in the verification status: mode already exists in the document schema and is read by the interpreter (interpreter.hpp: spec.mode = onceText("mode") == "date" ? DateMode::Date : DateMode::DateTime), but author::dateTimeInput(value, label, commit) has no parameter for it and never writes the "mode" key — so a hand-authored document node with .put("mode", "date") set directly would already render date-only, while the public wrapper function cannot reach that path at all. The fix for this half of the gap is narrow: add a mode parameter (or an options struct matching textInput's pattern) to author::dateTimeInput that writes "mode" when set to date-only. This is separate from the calendar-popup widget work tracked in this issue's main body — LicenceServer needs the mode fix to show a date without inviting a time-of-day the underlying value never carries.
3. Yaraslaut commented on Oct 22, 2026

   

   Yaraslaut

   on Oct 22, 2026

   MemberAuthor

   More actions

   Found and fixed a second, independent bug in the calendar popup itself while verifying it end-to-end against a real click (not just reading the code): MorphDateTimeInput.qml's openPicker() function sets picker.viewDate, picker.hour, picker.minute and picker.hasDay before calling popup.open() -- but the Popup's actual id is popup, not picker (every other reference in the file correctly uses popup.*). This is a plain reference-name typo: picker is never declared anywhere, so openPicker() throws a ReferenceError on its very first line and the function returns having never called popup.open(). Since QML swallows an exception thrown from a signal handler as a console-only warning, the calendar trigger renders and is clickable, but clicking it has had zero visible effect since the feature was written -- it looks like nothing happens, no error shown anywhere a normal diagnostic workflow (screenshots, log files, GUI test assertions) would catch, since the thrown exception never reaches any of those. Confirmed via a temporary try { root.openPicker() } catch (e) { field.text = "ERROR:" + e } instrumentation: the caught value was exactly ReferenceError: picker is not defined. Fix is a 4-line rename (picker. -> popup.) in openPicker(); verified the popup opens and a day can be picked after the fix.
4. Yaraslaut

   added 2 commits that reference this issue on Oct 22, 2026

   Declarative UI fixes: panel onToggle, table showHeader, row virtualiz…

   ...

   49e90e4

   Expose dateTimeInput's mode through an options overload (#1024)

   ...

   ba1d9c5
5. Yaraslaut commented on Oct 23, 2026

   

   Yaraslaut

   on Oct 23, 2026

   MemberAuthor

   More actions

   Partially addressed by #1038, which leaves this issue open.

   What #1038 does: dateTimeInput() gains a DateTimeInputOptions overload that exposes mode. This answers the open question in this issue's verification status: mode was already in the document schema and handled by the interpreter. Only the positional author wrapper didn't expose it.

   What is still missing (the core of this issue): the Qt Quick backend still has no calendar or date picker. #1038 doesn't change src/qt_quick/qml/MorphDateTimeInput.qml, so clicking the field still gives a text cursor. The spec decision in Scope item 1 (picker by default, a picker opted into via mode or a new option, or a separate node) is also still open, and so is the TUI-parity decision.

   Verification status: inferred from the PR's diff (file list and author.hpp hunk), not from running the app.

   Close when: the Qt Quick dateTimeInput offers a clickable date-picking affordance, and the spec records how it is chosen.
6. Yaraslaut

   added 3 commits that reference this issue on Oct 23, 2026

   Four remaining declarative-UI issues: Ghost emphasis, overlay width, …

   ...

   65fe24f

   Give every graphical date input a calendar

   ...

   e2d7a0d

   Give every graphical date input a calendar

   ...

   bdce168
7. Yaraslaut

   closed this as completedin #1040on Oct 24, 2026