KHolidays 5 branch

2014-12-28 Thread John Layt
Hi,

I've just pushed a new branch called kf5-port to the kholidays
repository for people to look at. This contains the set of api changes
I wanted to make and attempts to remove the kdelibs4support
dependency.

Could someone who understands CMake better than me have a look at the
last commit, as it refuses to link to QWidget once I remove the
kdelibs4support linkage.

Once that's fixed, what's the next step, do people want to see each
individual change go on review board? Or do I just push and get it
tagged for the next frameworks release?

The api changes are pretty self-explanatory, but there's a couple of
interim measures needed to plug gaps in Qt to allow removing
kdelibs4support usage:

1) I've replaced KCalendarSystem with a private copy of
QCalendarSystem until it is merged into Qt

2) I've had to import some private Qt code for converting ISO codes to
QLocale language and country enums until Qt adds the required public
api or I finish OpenCodes.

I've kept the astronomical and astrological classes, but haven't
looked at them in detail. I was wondering if we want to add private
d-pointers to them just to be safe?

Some other possible changes remain, but are not really necessary for
the first release:

1) Change from ki18n to tr

2) Make the widget and designer plugin build fully optional (any CMake
wizard care to do it?)

3) Add the Holiday Category public api

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: [Kde-pim] KHolidays 5 branch

2014-12-28 Thread laurent Montel
Le Sunday 28 December 2014 17:19:48 John Layt a écrit :
 Hi,
 
 I've just pushed a new branch called kf5-port to the kholidays
 repository for people to look at. This contains the set of api changes
 I wanted to make and attempts to remove the kdelibs4support
 dependency.

We can't for the moment see last commit.

 
 Could someone who understands CMake better than me have a look at the
 last commit, as it refuses to link to QWidget once I remove the
 kdelibs4support linkage.

Fixed now.

 
 Once that's fixed, what's the next step, do people want to see each
 individual change go on review board? Or do I just push and get it
 tagged for the next frameworks release?


Kdepim/kdepimlibs/pim* module compiles against this branch ?




 The api changes are pretty self-explanatory, but there's a couple of
 interim measures needed to plug gaps in Qt to allow removing
 kdelibs4support usage:
 
 1) I've replaced KCalendarSystem with a private copy of
 QCalendarSystem until it is merged into Qt
 
 2) I've had to import some private Qt code for converting ISO codes to
 QLocale language and country enums until Qt adds the required public
 api or I finish OpenCodes.
 
 I've kept the astronomical and astrological classes, but haven't
 looked at them in detail. I was wondering if we want to add private
 d-pointers to them just to be safe?
 
 Some other possible changes remain, but are not really necessary for
 the first release:
 
 1) Change from ki18n to tr
 
 2) Make the widget and designer plugin build fully optional (any CMake
 wizard care to do it?)
 
 3) Add the Holiday Category public api
 
 Cheers!
 
 John.
 ___
 KDE PIM mailing list kde-...@kde.org
 https://mail.kde.org/mailman/listinfo/kde-pim
 KDE PIM home page at http://pim.kde.org/

-- 
Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53,  http://www.kdab.fr


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel