On 24 September 2013 19:24, Kevin Ottens <er...@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. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
