kdeui splitup (widgets)
jlayt at kde.org
Thu May 3 22:19:38 UTC 2012
On Thursday 03 May 2012 18:19:33 Kevin Ottens wrote:
> On Sunday 29 April 2012 10:20:01 David Faure wrote:
> > or KCalendarSystem (might be fixed by Qt5, don't know),
> That one I'm not sure, I never manage to know where we are in that
> department on the Qt side... But AFAIK we're talking about only the 5 date
> related widgets.
My current plan is to spend May getting printing to be 5.0 release ready, then
to spend June implementing the ICU support for 5.1.
The API is actually going to end up looking a *lot* like KLocale and
KCalendarSystem. QDate and QTime will continue to be just containers with
their old calendar methods deprecated and only returning Gregorian. The local
calendar will be accessed via QLocale().calendar() which should make migration
a lot easier, it will mostly be the formatDate() and readDate() calls that
will need most conversion.
For kdeui, the only use of KCalendarSystem is in the date widgets. I'm not
sure what if any new date widgets Qt will offer, QtWidgets are "Done" but I'd
prefer to add new widgets rather than hack about with the old ones which are
very poor. Any new Qt widgets could be based on the new ones I wrote for KDE
4.6. If not we'll need to keep our own.
After a quick grep, the main use is in the .cpp, the only use in the API is in
setCalendar() and calendar(). In Qt 5 the plan would be to set the QWidget
Locale instead of the Calendar and access the calendar via that, so this API
is not required in Qt 5. The rest of the API will pretty much be unchanged.
Actually, that is a general point to note, in KF5/Qt5 all widgets should use
the QWidget locale() method when doing any localisation and not the global
application locale from QLocale().
Looking at the individual widgets, These we don't need so possibly K4Support:
Port to KF5 (and old version in K4Support?):
The table and picker probably need modernising, I seem to recall there being
something about them I didn't like.
If needed, I could do an interim port that removed calendar uses QLocale and
QDate for now, and then switch to locale.calendar() when it becomes available.
I'm not sure what we'd do with KDateTime when used in them.
Speaking of K4Support, how is that planned to be done? Will we be renaming
classes, giving them a different Namespace / library, or using different names
in KF5? How many of the old classes will we have in there, i.e. would we have
K4DatePicker in K4Support and KDatePicker in KF5? I'd think we would need all
the locale and date classes in K4Support?
More information about the Kde-frameworks-devel