QTimeZone merged for 5.2

[John Layt]

On 24 September 2013 19:24, Kevin Ottens <ervin at kde.org> wrote:
> On Tuesday 24 September 2013 19:03:21 John Layt wrote:
>> I'll do some analysis on the use of all the widgets and what ones are
>> worth keeping, and look at the Qt widgets to see if they're worth
>> switching to, if not before then at Qt Dev Days / Qt Contributors Day.
>
> OK, I'll ignore this part of KDE4Attic then and proceed with the rest. We
> really need to put this issue to a rest, it's been lingering for way too long.
> Really looking forward to your analysis!

Replying to all the list, damn gmail not knowing about mailing lists :-\

And here's my analysis :-)

tl;dr:
* Port KDateTimeEdit, KDatePicker, KDateTable and KTimeZoneWidget to Qt5.
* Move KDateTimeWidget, KDateWidget, KDateComboBox and KTimeComboBox
to kde4support

General rule:
Any widget that uses KDateTime, KCalendarSystem, KTimeZone, or KLocale
must either go to kde4support or be ported.  Porting would require
removing all uses of these K classes and using QDateTime, QTimeZone
and QLocale instead.  KCalendarSystem would be replaced by using
QLocale, as QLocale will embed the QCalendarSystem class to be used,
as well as translations, formatters, etc.  The widgets calendar api
setCalendar(), setCalendarSystem() and calendar() would be replaced by
setLocale() and locale().  No apps I checked currently use the
calendar api on the widgets.  Internal code accessing date/time values
like day() via KGlobal::calendar() would change to directly accessing
QDate or QTime for now, after Qt 5.3 they would then need changing
again to use QCalendarSystem via QLocale::calendar().

Method: Checked out all of the KDE SC, plus major gui apps from
extragear and calligra, then grepped for the class names.

Visual guide: https://www.dropbox.com/s/qkdgo5s68pg6tp6/KDateWidgets.png

KDateTimeEdit
- My new widget to replace many local widgets, added in last kdelibs release
- Can replace KDateComboBox, KTimeComboBox, api is almost the same
- Not used anywhere!?!
- API uses QDate, QTime, KDateTime, KCalendarSystem, KTimeZone
- Suggest: Port to Qt5
- KDE4 era apps can start pre-porting?
- Or add to Qt?

KDateTimeWidget
- Used 8 times
- API uses QDateTime
- Poor UX
- Suggest: kde4support, replace with KDateTimeEdit

KDateWidget
- Used 6 times
- API uses QDate, KCalendarSystem
- Poor UX
- Suggest: kde4support, replace with KDateTimeEdit

KDateComboBox
- Used 30 times, 29 in kdepim
- API uses QDate, KCalendarSystem, KLocale::DateFormat
- Forked by several apps due to lack of features, KDateTimeEdit
written to replace
- Suggest: kde4support, replace with KDateTimeEdit

KTimeComboBox
- Used 10 times, all kdepim
- API uses QTime, KLocale formats
- Forked by several apps due to lack of features, KDateTimeEdit
written to replace
- Suggest: kde4support, replace with KDateTimeEdit

KDatePicker
- Used about 20 times, but hard to tell due to forks and wrappers
- Forked and/or wrapped by several apps due to lack of features, needs
to be reviewed
- Uses QDate, KCalendarSystem
- Suggest: Port to Qt5

KDateTable
- Used directly 2 times, but is part of KDatePicker
- Forked and/or wrapped by couple apps due to lack of features, needs
to be reviewed
- API uses QDate, KCalendarSystem
- Suggest: Port to Qt5
- Maybe make private, have flag on KDatePicker to hide chrome?
- Make KPopupFrame private?
- Make KDateVaidator private?

KTimeZoneWidget
- Used 4 times
- API uses KTimeZone
- Unlikely to be included in Qt, so needed in KF5
- API looks a little old fashioned, users need major rewrite anyway
for QTimeZone
- Suggest: Port to Qt5?  Or start anew?

Cheers!

John.