Hi, I promised a mail of what to do with the KCalendarSystem, and finally here it is.
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? As such we need to limit any changes to ensure we maintain maximum source and behaviour compatibility, but still clean the classes up enough to ensure that if I fail we have maintainable code for the life of KF5. The code changes required to switch from KLocale/KCalendarSystem to QLocale/QCalendarSystem are significant, so most apps will likely take a while to switch, which only makes keeping KDE4 compatibility even more important. 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? John. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
