kcm: Prepare DurationPromptDialog for submission to kirigami-addons
I'd like to use the "ComboBox with duration presets plus customization via DurationPromptDialog" style of duration controls in the Power Management KCM. But it might also facilitate a form layout improvement in the Virtual Desktops KCM that I looked at today. The KDE Wallet KCM could use it for "Close Wallet" durations, and the Software Update KCM could consider adding a "Custom" entry in addition to its existing "Daily", "Weekly", "Monthly" and "Never" options. And that doesn't even get into use cases for apps, like my Android calendar app which uses a similar setup for notification times.
The ComboBox part still has too much boilerplate and will need to be looked at separately. As a first step, here are some improvements for DurationPromptDialog to incubate & adapt at the original location first, before opening an MR in kirigami-addons later.
It can now handle more possible units. We keep the existing API, but add unit options from milliseconds all the way to years in addition to the existing two options for seconds and minutes.
Custom footer buttons are replaced with a standard OK/Cancel setup. This renames the "Confirm" button to "OK", but that's not a bad thing in terms of consistency with other dialogs.
The subtitle property is renamed to "label", which more accurately describes its role and expresses the desire for a trailing colon.
Implicit width is specified such that a dialog without label will still be large enough to fully display its header and footer, with the main control horizontally centered in the dialog.
There is now only a single suffix label which picks its unit text dynamically, and tries to keep its width static (via TextMetrics) even in the fact of changing pluralization. It won't be perfect for all languages, but should be an improvement at least.
The file is relicensed from GPL to LGPL. Both myself and the file's original author, @merritt, agreed to this change.
FAQ
Why submitting only to kirigami-addons, instead of Kirigami proper?
- Because Kirigami, as a Tier 1 framework, can't use ki18n as dependency and that's sort of crucial in this component.