[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] KHolidays2 Plans
From:       Allen Winter <winter () kde ! org>
Date:       2014-12-18 15:15:47
Message-ID: 8842359.6soy8KRTTp () zazzy
[Download RAW message or body]

On Thursday, December 18, 2014 01:52:42 PM Daniel Vr=E1til 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 t=
hem someday.
But restoring them would be easy too.  So .. whatever the maintainer decide=
s is ok with me.



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