[Kde-pim] KHolidays2 Plans

[Allen Winter]

On Thursday, December 18, 2014 01:52:42 PM Daniel Vrátil wrote:
> 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.

Zodiac, et.al mentioned above are all mine for features I wanted to add to Korganizer
but never got around to implementing.   I still want those features.
They are stable and shouldn't need much in the way of care-and-feeding.

I'd like to see them kept alive, if only to give me some incentive to use them someday.
But restoring them would be easy too.  So .. whatever the maintainer decides is ok with me.



_______________________________________________
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/