Chinese Lunar Calendar Support in Kdelibs
johnlayt at googlemail.com
Wed Nov 10 15:31:25 GMT 2010
On Wednesday 10 November 2010 05:36:45 F H wrote:
> Hi all,
> It has been quite a few years since Liang Qi tried to add Chinese lunar
> calendar support in the kdelibs ( see
> http://lists.kde.org/?t=119817976300004 ) .
> Recently, I tried some effort to patch my local kdelibs (4.5.1) to get the
> lunar calendar supported. I would like to forward my patches to see if we
> can advance the job.
> There are two patches.
First of all, thanks for your efforts, as the maintainer of KCalendarSystem I
always welcome new contributions.
Unfortunately, this patch has exactly the same problems as the last one.
Firstly, it is not clear that the licensing issues have been resolved. While
the required ccal code has been relicensed under the LGPL (I have yet to do a
full file-by-file check), it also includes copyright statements for the Lunar
Outreach code for which the licensing is unclear. It was "for non-commercial
use only", Liang Qi said it had been relicensed but the link he gave is now
dead. That code seems to just be standard algorithms from "Astrinomical
Algorithms" by Meeus and could probably be easily replaced with something more
appropriate from the LGPL libnova (which is a full implementation of Meeus).
In fact, I'd be happier if the NOVAS stuff came from libnova as well if
possible, but that's more from a style and ongoing maintenance point-of-view.
Secondly, it is still all in one big block and needs to be broken down into a
proper class structure that can be reused by other astronomical calendars.
I'm not sure why the ccal classes that were neatly separated have been cut-
and-pasted into a single class, wouldn't it just be better to copy the classes
as-is into a sub-directory where they would be easier to keep in sync with any
ccal bug fixes? Even then, that still leaves a lot of style and api issues to
Also the way you have implemented KCalendarSystemChinese itself is not right,
that class should fully support the Chinese Calendar as a standalone calendar
system, i.e. have the day() method return the Chinese day number, year() the
Chinese year number, etc. Then the calendar could be used for anything,
including calculating holidays, not just displaying a day number alongside the
Gregorian. Basing off Gregorian and modifying the dayString() call like you
have would affect every app that displays a date using dayString(), and so
every app would need to be checked and possibly fixed to display it correctly
like you did in the calendar widget, so that's not the right approach.
Instead using a standalone Chinese Calendar class, the plasma calendar (and
any other app) would have a special mode to display two calendars at once
(usually known as 'Alternative Calendar' in the PIM world). This would be
more flexible as each app can adjust the display of the two numbers to what
best suits its available space, and it could be used by people in other
countries with two calendar systems, not just Chinese. Fortunately, there's
really only 3 places this would need to be done, KDateTable, Plasma
CalendarTable, and in KDEPIM (where it's already on the feature todo list).
Besides all that, the 4.6 feature freeze is tomorrow, so there's no time left
to fix this up.
That's the bad news, on the good news front, my desk is littered with books on
Celestial Mechanics and Astronomical Algorithms, and I've been talking to the
KStars and Marble teams about the needed astronomical functions and building a
shared library to provide them to all of KDE. With this or libnova as a base
we should have something basic in place for 4.7.
After the freeze tomorrow I'll have time to go over this properly and get back
to you to discuss what needs changing.
More information about the kde-core-devel