KCalendarSystem et al.

[Kevin Ottens]

On Monday 21 January 2013 20:25:47 John Layt wrote:
> Let's quickly recap.  The plan is to switch to using native Qt classes and
> api for all locale, date and time zone functionality.  This is dependent on
> my adding calendar and time zone support to Qt.  Qt decided they wanted
> this done using ICU so I'm coding that and have about 4 weeks left to make
> it happen for 5.1.  If I pull it off, then KLocale, KCalendarSystem,
> KTimeZone, KDateTime and related classes will all end up in KDE4 Support to
> ease porting. If I don't then they will continue to exist in wide use for a
> while longer, but possibly still in KDE4 Support so we can make a switch
> later?

Well, that depends... If it moves in kde4support then the other frameworks 
can't use them and would have to switch to the Qt classes. Therefore it'd help 
a lot to know if that would badly break something or not.

> So what do I think should change in KCalendarSystem?
> * Synchronise date calculations with Qt5, i.e. remove KQDateCalendarSystem
> * Synchronise the base class API to match the Qt5 QDate API changes, mostly
> just using qint64 instead of int, etc
> * Change the KCalendarSystem public base class to no longer be virtual or
> have derived sub-classes.  This is an artefact of the early days when it
> was thought people would sub-class their own calendar systems, but this
> really didn't happen.  In KDE4 this became a problem as we hadn't reserved
> more virtual slots, so new features couldn't be virtual.  Instead I put the
> new logic into the private class and made that virtual instead.  For KF5 we
> should try remove the virtual from the public base class, remove the
> derived base classes, and have a single public class with a virtual private
> class that the specific calendars are derived from.  This is SC as apps
> only use
> KCalendarSystem via a factory method.
> * Performance optimisations are good but should not affect code
> maintainability or make maintaining BC more difficult.
> 
> I could do a review of the API, there are a number of methods I'd like to
> delete rather than just mark as deprecated as they are really internal
> implementation details and are not used elsewhere, or are plain wrong, but
> that's up for debate if it's acceptable.
> 
> Thoughts?

Is it that reasonable to put so much effort in those classes if their fate is 
kde4support? I'd rather see us leave them alone if that can make the necessary 
Qt5 changes and the frameworks porting to QLocale/QCalendarSystem happen 
earlier...
 
Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130124/4bd3c20a/attachment.sig>