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

liuspider

现在最大的问题是，klocale本身对日历系统的处理过多的考虑了向后兼容性，从而扩展性十分困难

不明白你指什么:能否具体点?

bamfox

liuspider，可以先搞一个独立的程序吗？

mandrakechina

klock就是kicker里的时钟啊

klocale本身的问题就是它目前十分难于扩展，因为它是基于一种单一的日历系统来设计的。现在引入了伊斯兰历(好像是这个吧)以后，你只能选择其中一种日历系统。但我从来不认为使用伊斯兰历的人会只需要伊斯兰历，可以完全用不着公历。从国家标准时上面，他们也一定是使用公历的，而以伊斯兰历作为辅助。这和中国的情况是一样的。

为了让klocale可以同时支持多种日历系统，并让这些日历系统有优先级可选，必须完全打破现有的体系。这就是向后兼容带来的问题。为了实现新框架，你必须背着向后兼容这个大包袱。

我之所以对引入XML/XSLT和插件体制不持肯定态度，是因为我觉得没有必要，而且和KDE自身的东西很难融合到一起。等于是你为了多日历系统完全创造出了另外一套体系，而这个体系和KDE现有的任何东西都没有任何关系。感觉这样复用率极低的东西，KDE恐怕更不会接受

我的意见是，可以先把农历算法KCalendarSystem提交上去，先把农历实现起来再说。至于如何在系统中应用，这个要和KDE开发者进行磋商后再作定夺。

bambox，独立的程序没什么使用价值。而且，一旦这个东西放出去了以后，就会有很多特别无理的要求提上来，因为日历系统根本不是给最终用户的。况且一个日历系统的实现实在不是什么大程序。你看过KDE的类结构就知道了，任何一个KDE程序都可以在十行代码之内实现对农历的调用。

liuspider

bamfox,
现在用来调试的是一个独立的程序，但是现在仅仅是原理上通过，还完全不可用

liuspider

为了让klocale可以同时支持多种日历系统，并让这些日历系统有优先级可选，必须完全打破现有的体系。这就是向后兼容带来的问题。为了实现新框架，你必须背着向后兼容这个大包袱。

向后兼容我想是必须考虑的问题的...

我之所以对引入XML/XSLT和插件体制不持肯定态度，是因为我觉得没有必要，而且和KDE自身的东西很难融合到一起。等于是你为了多日历系统完全创造出了另外一套体系，而这个体系和KDE现有的任何东西都没有任何关系。感觉这样复用率极低的东西，KDE恐怕更不会接受

其实我的那个方案，仅仅需要修改那几个核心的 date 类 (KDatePicker KDateTable), 在他们的实现中添加 plugin/xml 支持：而其他的程序（如klock），不需要什么修改的，当然可能需要多加一个配置选项什么的

我是觉得那个方案还是有很大的机会获得接收的

我的意见是，可以先把农历算法KCalendarSystem提交上去，先把农历实现起来再说。至于如何在系统中应用，这个要和KDE开发者进行磋商后再作定夺。

到目前为止还没有人给我建议，在 KDE ML 上

mandrakechina

你先把农历算法发到我的那个bugreport上。先把算法弄进去再说其它的。

liuspider

发是肯定会发的，不过现在还没最终做好

wudiapple

我也想参加核心算法，俺的qq：342557712 或发信[email protected] :-)

bamfox

[quote:3c380f7b4c="wudiapple"]我也想参加核心算法，俺的qq：342557712 或发信[email protected] :-)[/quote]

请自行加入相关的邮件列表，主动一点，好吗？请不要介意我回复晚了点。

iamathinker

网上已经有中国日历的源代码了。

是一个高人对着万年历整理出来的。

rokeeme

QQ 昵称：横刀（54125653）
参加方向：GUI
msn:[email protected]

rokeeme

网上已有一个gctc的一个东东，但这不重要，重要的参与和以及在这过程中的收获与快乐

ty263

我想参加，
哪个组都可以，按需分配

E-Mail: [email protected]

chinafire

我也来
QQ：44929007
参加方向：核心算法部分

yuyulvxian

QQ 贤:372241110
参加方向：核心算法