| Summary: | How about a KCalendarSystemChineseLunar? | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Funda Wang <fundawang> |
| Component: | kdecore | Assignee: | John Layt <jlayt> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | CC: | bolingh, cavendish.qi, jlayt, qydwhotmail |
| Priority: | NOR | ||
| Version: | SVN | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Other | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Funda Wang
2004-02-10 06:53:30 UTC
Anybody please check this: http://sf.linuxforum.net/project/showfiles.php?group_id=34 The only thing you should do is to port it into KDE Calendar. I have had contact from other people wishing to see a Chinese calendar implemented and have had some code submitted that unfortunately had licensing issues. I am looking for alternatives to the problematic code and hope to have something for 4.3. Assign to me to action. http://code.google.com/p/kcalendar/source/browse/#svn/trunk/kde4 Code written two years ago. I don't know if it fits the framework of KDE 4.4. Why remove me from the cc: list? This code was rejected by me mainly due to licensing issues, but also due to architectural issues. Some of the code was originally licensed under terms incompatible with the KDE policies, and I saw no documentation from the original authors relicensing the code or granting permission for it to be copied. In short, it would have been illegal for us to distribute it, or illegal for commercial distributions to do so. (The NOVAS code was fine, it's Public Domain). Architecturally, I wanted to see the astronomical code split into their own classes and made more generic and KDE/C++ like so they could be reused in other lunar calendars, and in a new version of KHoliday that the kdepim guys want to write. While keeping it internal to the Chinese class would have been OK to start with, it really was a giant undocumented mess of C code dumped into KDE with no clear ability for it to be maintained or supported. I would prefer we either found a single C++ source of code or a library for all the calculations required that has a clear support path for bugfixes and security patches, or write our own from scratch in a consistent and KDE like fashion that we understand and can support. There were also a lot of minor issues that needed cleaning up, like it was undocumented, not kdelibs standards compliant, re-implemented code that already existed in the base class, etc. It is on our todo list, I've had more time lately for calendar work (hence the 5 new calendar systems supported in 4.4) and I'm now hoping to get this done for the 4.5 release. Oh, I should add my preference is to co-ordinate with the KStars project to see if their astronomical code can be used. There is also libnova an lgpl library which could be used instead: http://libnova.sourceforge.net/ but that would need to be discussed to see if we are willing to make kdelibs dependent on it. Moved to 429892 *** This bug has been marked as a duplicate of bug 429892 *** |