[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-pim
Subject: Re: [Kde-pim] KHolidays2 Plans
From: Daniel =?ISO-8859-1?Q?Vr=E1til?= <dvratil () redhat ! com>
Date: 2014-12-18 12:52:42
Message-ID: 1542135.xJbGsjQ7Sz () thor
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
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@kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
--
Daniel Vrátil | dvratil@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
["signature.asc" (application/pgp-signature)]
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic