Chinese Lunar Calendar Support in Kdelibs

[John Layt]

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.

Hi,

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 
be fixed.

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.

Thanks again,

John.