kdeui splitup (widgets)

[John Layt]

On Friday 04 May 2012 10:17:32 you wrote:
> On Thursday 03 May 2012 23:19:38 John Layt wrote:
> >
> > I'd think we would need all the locale and date classes in K4Support?
> 
> Can't really answer that before seeing what the porting effort from the old
> to the new locale stuff will be. If it's not much, then maybe you want to
> break SC rather than offer the complete whole stack. Otherwise, yes, this
> might be an option.

Most KLocale methods like setDecimalPoint()/decimalPoint() are used in very 
few places in KDE so won't take much effort to port.

For the widgets we're keeping, there's only a couple of places that use their 
setCalendar() / calendar() api, so that's an easy port as well.

The methods accessed via calendar() will probably need little change as the 
new QCalendarSystem api will be very similar, so mostly changing 
KGlobal::locale()->calendar()->xxx to be QLocale().calendar().xxx.  LXR says 
there are about 8,500 uses of such methods, although there could be a lot 
false positives as grep only shows about 500 uses of calendar()->.

The real problem comes with the 2,200 uses of the formatXxx()/readXxxx() 
methods which need to be changed to toString() / fromString().  Most will just 
be default usage, but many will need new format strings or enum values so 
can't be easily automated.

[Note these numbers include extragear and calligra]

For those numbers some kind of support code is going to be needed, but there 
could be problems if an app uses both KLocale and QLocale at the same time as 
there is the chance for there to be differences in the settings and the 
results of format/parse even if they have the same locale set.

I see 4 options:

1) Keep all of KLocale and KCalendarSystem and associated widgets in K4Support 
and accept the risk of inconsistencies, or recommend a big-bang switch for 
each app.

2) Convert KLocale to read settings from QLocale instead of our own files, but 
still keep our own format and calendar code, still have a small risk of 
inconsistencies.

3) Convert KLocale to just be a wrapper around QLocale that passes all calls 
to QLocale.  No inconsistencies, but a lot of mapping code to maintain.

4) Create a new class K4Locale that maps only the most used read / format / 
calendar calls to QLocale but removes the rest of the old KLocale api.  No 
inconsistencies and less mapping code.

Options 2 or 4 seem the more sensible, and would keep K4Support smaller by not 
needing to keep our locale files or needing all the other widgets.

Cheers!

John.