[kde-guidelines] Date/Time picker (Was: Grunt work)

[Aurélien Gâteau]

On Thursday 04 July 2013 12:55:31 Thomas Pfeiffer wrote:
> On Thursday 04 July 2013 12:07:46 Heiko Tietze wrote:
> > Am Dienstag, 2. Juli 2013, 17:13:57 schrieb Aurélien Gâteau:
> > > > * Allow direct input at the input field (e.g. to copy/paste values).
> > > 
> > > I don't think this line is necessary: this is the default behavior when
> > > using KDateComboBox and KTimeComboBox.
> > 
> > Removed. But I'm afraid we exclude all important reasons because function
> > is inbuilt.
> 
> Sure it does feel weird to leave out important things, but I agree with
> Aurélien that we should only only add guidelines for things which developers
> may actually screw up. If we can prevent errors by now allowing them to be
> made on a technical level, redundantly discouraging them via guidelines may
> confuse developers more than it helps them.
> 
> > > > * Insert current time or date into into input field on user reset.
> > > 
> > > What do you mean with "user reset"?
> > 
> > The small icon/button right hand of input fields. Usually the input field
> > is cleared when this object is clicked. But that's not a good idea for
> > masked edits, and some generic input like 00:00 or 01.01.1970 is
> > inappropriate as well.
> 
> I could not find the clear buttons in any real-life date or time pickers in
> KOrganizer and Date and Time settings. Which widgets are they using?

Just checked: they use KDateComboBox and KTimeComboBox, but have some 
slightly-hackish code to disable the clear button.

> Do the
> clear buttons really make sense for date and time pickers?

You tell us :) More seriously, I have the feeling the clear buttons should go, 
or at least be off by default. If one needs to allow empty date it is probably 
better to do so by disabling the widget with a checkbox or something like 
that.

> What's missing is a clear distinction between K{Date/Time}ComboBox  and
> KDateWidget / KDateTimeWidget. They clearly have different purposes, but
> currently the criteria in the guidelines are very vague.
> 
> I'd suggest to replace the first two guidelines with the following:
> 
> "In situations where users enter a date that they already know for certain
> (e.g. their birthday), use a KDateWidget. If they want to enter a date and
> time they already know exactly, use a KDateTimeWidget.
> If users want to choose a date and time using the application (e.g. while
> scheduling an appointment or choosing a date for a vacation), use the
> KDatePicker or KDateComboBox (depending on the amount of space available)
> and KTimeComboBox.
> If users want to browse through dates (for example when viewing a calendar
> or browsing a history based on the date), use a KDatePicker for convenient
> switching with a single click."
> 
> Does that distinction make sense to you?

Kind of, but it still sounds a bit like find a reason for something which did 
not have any reason to exist initially :)

Did I mention I deliberately decided not to include yet-another date-time 
widget provided by kdelibs because it does not seem to be used (but provide 
interesting features like picking whether you want a Gregorian or a Julian 
calendar). I think we have too many date/time classes.

Maybe we could instead say the K*Widget classes are deprecated and suggest 
developers should use the K*ComboBox classes instead? From a code point of 
view, we can't remove classes from kdelibs4 but we can mark classes as 
deprecated. This will trigger warnings next time developer rebuilds his 
application.

If we go this way it would make sense IMO to create a KDateTimeComboBox which 
would combine both K*ComboBox. What do you think?

Aurélien