kdeui splitup (widgets)

[John Layt]

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:

 * KDateWidget
 * KDateTimeWidget

Port to KF5 (and old version in K4Support?):

 * KDateTable
 * KDatePicker
 * KTimeComboBox
 * KDateComboBox
 * KDateTimeEdit

The table and picker probably need modernising, I seem to recall there being 
something about them I didn't like.

Don't know:

 * KTimeZoneWidget

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?

Cheers!

John.