On Tue, Jul 16, 2013 at 2:02 PM, Kevin Krammer <kram...@kde.org> wrote: > On Tuesday, 2013-07-16, Mark wrote: > >> >> Actually.. i don't mind those sets to be "KDE 5" material. It can't be >> >> used for any KDE 4.x series anymore since the workspace is on lockdown >> >> after 4.11 thus those components can't even be used to recreate the >> >> calendar popup for 4.11 or 4.12.. >> > >> > They can still be used for separately shipped applets, etc. >> >> That depends on the Qt ICU efforts in bringing a calendar system to Qt >> which was intended to happen if i recall correctly. I just don't know >> for which Qt release. > > Rather irrelevant for KDE technology like Plasma, KDE has had proper calendar > code for years. > >> Now assuming Qt calendar stuff is going to be in Qt in 5.2 (or 5.3) >> then i prefer: >> - Keep using Q* classes as much as possible since they are going to >> contain the KCalendar* classes. (assumption) >> - be KF5 only material (although right now it works with Qt 4.x) > > Your choice of course but I wouldn't be happy to develop something and then > have it sit there unused for more than a year.
True, and that argument alone lets me lean very much towards the KCalendar stuff. I think i'm just going to follow you on this and go for KCalendar and friends. It can't be that hard to port it to QCalendar and friends once that is released. I could also make an abstraction to make it to toggle between KCalendar and QCalendar although the later one would be a stub implementation at this moment. That does make it very easy to switch to a different API in the future. > > Cheers, > Kevin > > -- > Kevin Krammer, KDE developer, xdg-utils developer > KDE user support, developer mentoring > > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
