[Kde-pim] KHolidays2 Plans

Daniel Vrátil dvratil at redhat.com
Thu Dec 18 12:52:42 GMT 2014


On Monday, December 15, 2014 05:59:20 PM John Layt wrote:
> Hi,

Hi John!

> 
> I think I've mentioned this before but just to clarify where I see
> KHolidays heading:
> 
> 1) KHolidays2 (5?) will be a quick port of KHolidays to Qt5 /
> Frameworks Tier 1. This is intended as a short-to-medium term
> solution. The API will be cleaned up with deprecated methods removed
> and a few items renamed for clarity but not radically altered. The
> data files and parsers will be unchanged. The major task is removing
> KCalendarSystem and thus the kdelibs4support dependency (but we could
> still release without this step as it won't affect BIC).
> 
> 2) Long term I still hope to get OpenHolidays implemented with Open
> Data JSON files shared with other projects, but that's on the
> back-burner for now.

Will this affect the API, or is it just an internal change?

> Current status for KHolidays2 is everything except the KCalendarSystem
> removal has been done, and I plan to complete that in the next couple
> of weeks during the holidays :-) All going well, we should be ready
> for the February Frameworks release.

Awesome \o/

> 
> One question for the list is do we keep the Zodiac, SunRiseSet,
> LunarPhase and AstroSeasons classes? These are not used *anywhere* in
> KDE and are code and api I have never even looked at. As far as I am
> concerned it is dead code and could be dropped rather than expend
> effort on reviewing and updating it in time for the earliest possible
> release. OTOH, maybe it's not used because people don't know it
> exists? It can be argued that KHolidays is a good place for it as they
> can be used in calculating holidays and other events to display on a
> calendar. It could also argued astronomical calculations should be in
> an astronomical library where specialists can maintain it :-) Perhaps
> a third option is to make them private for now and review them at our
> leisure. Thoughts?

Once you make it private, it will rot even more :-) I would say it should 
either be left public and better advertised (as one of the "kool features"), 
or it should be removed completely.

Cheers,
Daniel

> 
> Cheers!
> 
> John.
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141218/b763b891/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list