中国日历开发计划（0.1V）

omron

算法很简单，查表呀

liuspider

公历->农历 转换核心已经移植完成

算法基于那个网站，已经给那个原作者发信了，希望他能同意以GPL2发布我现在写的这些东东

omron

这个算法网上多的是，不知道谁是最先想出来的

omron

http://www.snowfoxstd.com/Html/Chs/default.htm
这个不错

liuspider

核心基本上全部完成，再加上 翻译 系统，就可以提交了

已经获得原作者许可

小锁

liuspider真的很勤劳啊！

mandrakechina

[quote:1847419cbf="liuspider"]核心基本上全部完成，再加上 翻译 系统，就可以提交了

已经获得原作者许可 [/quote]是在KCalendarSystem上写的么？如果是的话，直接在bug#74793粘上附件就行了

如果是一个application的话，还是算了。

bamfox

[quote:6ad8d980cd="liuspider"]核心基本上全部完成，再加上 翻译 系统，就可以提交了

已经获得原作者许可 [/quote]

可以发到邮件列表大家测试一下 :D
谢谢

liuspider

mandrakechina,
是的，我就是 sub-class 的 KCalendarSystem，不过为了调试，我还写了个 application

多谢你指出的那个bug，我会在那提交的，不过我想在提交之前，先做些测试

那个 bug 里面提到一个 万年历，看上去比我现在用的这个方案好：可以算 -850 年到 2100 年（现在完成的这个是 1900-2100的）

还没仔细看，如果那个核心也不是很复杂的话，我会考虑基于那种算法重写一下。尽管我个人觉得 1900-2100的这个范围已经可以满足决大多数人的需求了...

bamfox,
请问你是指哪个 ML？

我现在还没提交农历核心的另一个主要原因是，我还没有想好怎么在 KDE 中将它充分利用起来... 我在 KDE ML 上问了，现在还没有人给我进一步的建议

我想的是：(copied from my last email to kde-dev ML)
Now I am playing with a test program (called kalendar), which has its
only implementation of KDatePicker, and now I'd like to add my own
KDataTable.

IMO, the requirements for the new KDataTable is as follows:
1. the available info of each day, is supplied by plugins
2. In each of the cell (a day), the layout of the information is
customizable by the user (this including whether or not a specific
info should be displayed or not)

My proposed way of implementing this is to provide a XML document
type, and each plugins can insert its own info into the doc: all
information from enabled plugins are made available in the XML doc.
What and how to present to the user in each cell in KDataTable is
determined by a xslt transform file (like the way in kopete chat
window customization)

Comments are highly welcomed. Thanks.

当我实现了这一类的一个应用后，我才能好好测试现在的这个 KCalendarSystem 核心

mandrakechina

现在最大的问题是，klocale、klock似乎都没有支持CalendarSystem，要打很多patch。唯一的作用是创建korganizer的插件，而且搞不好还得通过GHNS来实现

我对你的datetable的意见是，不要使用插件，这样会使得程序变得很难于控制。如果要实现你说的功能，我的想法是这样的：

在klocale中列出所有可供选择的日历系统，用户可以选择我想要使用哪些日历系统。现在只能选择一种日历系统，这是不对的，因为中国用户要同时使用公历和农历，而且公历比农历重要。所以可以考虑带有优先级顺序的checklist。

启用了相应的日历系统之后，在klocale的日期格式中可以进一步设定日期的格式，这需要对现有的格式系统进行相当程度的扩展。

klock应该也可以自定义所使用的日期格式。这意味着可能需要为klock添加一种全新的显示方式。

至于datepicker，可以从klocale读取优先使用的日历系统，然后在tip里使用klocale中设定的日期格式显示启用了的所有日历系统。

bamfox

liuspider, 我说的是 MagicLinux  
你已经把这个东西搞出来了，真是大大促进了农历在 Linux 中的应用啊。

加油呀！  

liuspider

唯一的作用是创建korganizer的插件，而且搞不好还得通过GHNS来实现

korganizer的插件 相对来说是最简单的了，没什么工作量。 我对 newstuff 也没什么反感的，要做也没什么意见。但是关键在于，我希望的是在 KDE 中的所有的使用日历的地方，都可以出现农历的信息

我对你的datetable的意见是，不要使用插件，这样会使得程序变得很难于控制。

插件本身没什么关系，我觉得 xml + xslt 是最麻烦的，在我的那个 proposal 中...

你的想法看上去不错，而且实现起来的复杂程度好像比我设计的小一些（？），但是有两个问题：
在 Time & Dates 下面，你只能设置："Date format" 和 "Short date format"，如果你在里面加入 农历的信息的话，所有显示日期的地方（KDE中）都会包含这个了：我觉得不是所有地方都需要的。而如果再新加一种 date format的话，那还是要去改 很多其他的程序。

另一个考虑是：这些修改必须是有可能被 KDE 官方接受的，我不想去做永远都是 patch 的东东。而我觉得你提出的这个方案可能会比较不容易被接受，或者说改动面太大

至于datepicker，可以从klocale读取优先使用的日历系统，然后在tip里使用klocale中设定的日期格式显示启用了的所有日历系统。

这样做可行（如果 对 klocale 的 日历选择可以被改成 一个 list 的话），但是使用起来就没那么方便了：我还是希望可以在我计算机上有一个和普通的日历那样的一个程序：所有的信息都是直接写在那一天的。

liuspider

我说的是 MagicLinux

不好意思，我没有加入那个 mailing list，而且我也没有使用 MagicLinux，所以我加入好像也不合适

你已经把这个东西搞出来了，真是大大促进了农历在 Linux 中的应用啊。

现在只有一个核心，还没想好如何和现有程序整合到一起，所以还没什么应用（目前来说）

mandrakechina

现在最大的问题是，klocale本身对日历系统的处理过多的考虑了向后兼容性，从而扩展性十分困难。如果势必要写代码的话，差不多要把日历系统的管理重写。如果要重写的话，不如设计一个一劳永逸的framework。而且，只要对外可以实现与原来一样的功能，内部怎么写关系应该不太大。

至于在所有显示日期的地方都显示出农历，好像没什么用。比如你会希望在filelist的modified date中显示农历么？目前实际可以用到农历的地方，一个是klock，另外一个就是PIM中的日程管理(korganizer和kplato)。如果光考虑这两个东西的话，也许更简单一点，我们连klocale都不用动，直接对klock打patch，然后做korganizer的插件就行了。了不起再写一个superkaramba的模块。

liuspider

至于在所有显示日期的地方都显示出农历，好像没什么用。比如你会希望在filelist的modified date中显示农历么？

这种地方肯定不需要了

目前实际可以用到农历的地方，一个是klock，另外一个就是PIM中的日程管理(korganizer和kplato)。如果光考虑这两个东西的话，也许更简单一点，我们连klocale都不用动，直接对klock打patch，然后做korganizer的插件就行了。了不起再写一个superkaramba的模块。

klock 没用过(也没安装)，但是我觉得还有一个很重要的地方: the clock applet in kicker!  他是我想第一个解决的

现在我就是在考虑一个 framework 来给所有的需要的应用提供一个框架，所以才有我那第一个 proposal。你所说的那种一个 程序 打一个补丁的方法，我是比较难于接受的(我是说如果没有一个框架而是各自为政的话)