Magic Linux 1.2 RC3 修正(1月26日)

jackey

作为螃蟹第二人，我现把RC3需要进一步修正的问题列在这儿，大家补充。
我用10分钟装完了RC3,机器配置AMD XP 1.15G 512 DDR.

1. 首次起动时，initscript有错误，但不影响启动


2. fcitx有三个问题

1. 其分类不应该是中文，而是应该归入User Interface->Desktops。
2. 默认字体应该同一由12号改成10号
3. 中文输入默认标点符号为英文（点一下就好了），这个问题不大，但是...[/list:u]

3 azureus 内核要更新

4. ntpd 时间校准有问题
怀疑是配置或丢失了依赖包
5. /etc/xpdfrc simhei.ttf 路径错误
请加入下列两行
[code:1]
displayCIDFontTT Adobe-GB1 /usr/share/fonts/ttf/zh_CN/simsun.ttf
displayCIDFontTT  Adobe-GB1 /usr/share/fonts/ttf/zh_CN/simhei.ttf
[/code:1]
kanker你更正一下kdegraphics。
同时kanker修改konqueror默认pdf关联配置，让看konqeror每次自动调用kpdf，而不是调用kghostview。现在的kghostview有问题，不能万全工作。一般的pdf中文pdf没有问题，但是我读lshort-cn.pdf就不行，kpdf没有这个问题。也许是那儿配置不对。

6. konqueror tab功能有一个bug
看图左边

thurderbird

没见Magic Linux 1.2 RC2，这么快有RC3了
Magic Linux 1.2 RC3哪里有下？

baif

找找kanker。

bamfox

你十分钟就装完了，我的 p4 2.4c 1GDDR 双通道，都没有这么快过。
难道说 ML 又有超级更新 :D

llc

RC3里，konqueror对中文文件名的排序正常了吗？这个好像是KDE的bug吧？

KanKer

[quote:26ce8ff9d9="llc"]RC3里，konqueror对中文文件名的排序正常了吗？这个好像是KDE的bug吧？[/quote]

是什么问题？linux不支持拼音排序。可以看看gnome有没有相同的问题

llc

见这里：
http://www.linuxfans.org/nuke/modules.php?name=Forums&file=viewtopic&t=97803&postdays=0&postorder=asc&start=90


我记得rh8和ml1.1时konqueror是中文名是按拼音排序的
估计1.2RC的GNOME也有这个毛病，因为我在B.M.P里选择mp3文件时，在对话框里发现那些中文文件名的MP3文件排序也是一团糟糕……这么说来不是konqueror的问题，究竟是哪里的问题？
如果文件管理器连对中文文件名的排序都出现问题，很难说得过去

bamfox

调试用的包 gdb 在 RC3 上装了没有呢?

cjacker

Unicode中的汉字是采用部首加笔画排序, 部首加笔画的顺序就是Unicode编码的顺序.

export LANG=zh_CN.EUC
export LC_ALL=zh_CN.EUC
konqueror
这样，konqueror就以拼音排序了。

这个跟locale的定义有关系。

cjacker

补充一下，这个是因为历史原因造成的，一级码是按照拼音排序的，后来的基本就是按照笔画，笔顺来排的。

显示的时候跟LC_COLLATE有关系，比如，上面的例子，你不论是使用什么样的locale
只要export LC_COLLATE=zh_CN.EUC之后就可以按照拼音排序了，当然，应该不会遇到gb18030的字符的时候。

目前，国家正在制定的18030排序标准是这样的：
1，笔画不同时，笔画少的在前
2，笔画相同的时候，按照横先于竖，竖先于撇，撇先于点，点先于折
3，如果笔顺也相同，要根据折点来排
等等。


按照目前的情况，要去修改这么大的一个码表看来是不可能了，所以，collate怎么定，就怎么排好了。

如果非要按照拼音，那么就按照我说的：

export LANG=zh_CN.GB18030
export LC_ALL=zh_CN.GB18030
export LC_COLLATE=zh_CN.EUC

这样就可以应付一般简单汉字的拼音排序了，如果你够幸运，没遇到生僻字，呵呵。
切记:万万不可作为系统全局设置，不然会遇到很多不可思议的问题，呵呵。

按照中文习惯的排序方法还是好一点。


关于LC_COLLATE，参看glibc的locale实现。

llc

目前，国家正在制定的18030排序标准是这样的：
1，笔画不同时，笔画少的在前
2，笔画相同的时候，按照横先于竖，竖先于撇，撇先于点，点先于折
3，如果笔顺也相同，要根据折点来排
等等。

不是吧，这样的排序合理吗？不符合习惯吧？
如果我要在一堆中文名字的文件中查找一个文件，还得数数笔画才能找到？数完笔画后，万一遇上很多相同笔画的，还得回忆起“2，笔画相同的时候，按照横先于竖，竖先于撇，撇先于点，点先于折；3，如果笔顺也相同，要根据折点来排”这些规则来查……不是这么无聊吧，撞豆腐撞死算了
为什么windowsXP的“按名称排序”不使用笔画排？

cjacker

[quote:3e09db9d5e="llc"]

目前，国家正在制定的18030排序标准是这样的：
1，笔画不同时，笔画少的在前
2，笔画相同的时候，按照横先于竖，竖先于撇，撇先于点，点先于折
3，如果笔顺也相同，要根据折点来排
等等。

不是吧，这样的排序合理吗？不符合习惯吧？
如果我要在一堆中文名字的文件中查找一个文件，还得数数笔画才能找到？数完笔画后，万一遇上很多相同笔画的，还得回忆起“2，笔画相同的时候，按照横先于竖，竖先于撇，撇先于点，点先于折；3，如果笔顺也相同，要根据折点来排”这些规则来查……不是这么无聊吧，撞豆腐撞死算了
为什么windowsXP的“按名称排序”不使用笔画排？[/quote]

目前不是这么做的，这是一个要制定的标准。

locale是自己可以定义的，所以LC_COLLATE是可以自己构建的。

如果windows XP不按笔画，那么说明了一个问题，就是他肯定做的不健全，因为18030有数百字根本就没有拼音。

中国人的习惯就是按笔画，你看人名列表不都是按照笔画排吗？

古代的检索方法也是笔画，很少有读音的。

因为读音是个非标准的东西，如果按照读音排序，也仅仅是在普通话里面有效。

llc

如果windows XP不按笔画，那么说明了一个问题，就是他肯定做的不健全，因为18030有数百字根本就没有拼音。

中国人的习惯就是按笔画，你看人名列表不都是按照笔画排吗？

古代的检索方法也是笔画，很少有读音的。

因为读音是个非标准的东西，如果按照读音排序，也仅仅是在普通话里面有效。

XP确实是按拼音排，而且印象中全部win系列都是按拼音排，以前的rh8、ML1.1也是按拼音排
或者win里对那些没有拼音的那些字另有处理

个人认为：
按拼音排更符合操作习惯，当你第一眼看到一个字时，下意识的反应是它的拼音读音，而不是去留意它的笔画多少；而且普通话是国语，具有广泛性，按拼音读音排序没有不合理之处

或者win系列对排序的处理不健全，但“按拼音”排序应该是它做过广泛调查之后才制定下来的贴近用户习惯的排序方法，估计将来的win中文版本仍然会采用“按拼音”排序

WIN的设计每一处都经过仔细调查和考虑才决定下来，力求能最贴近用户最方便用户；可以鄙视MS的精神，可以蔑视MS的行为，但不能不重视MS的设计

cjacker

上面我也提到了，可以通过自己定义LC_COLLATE来实现，不过可能用户不会这么作。

Win的拼音排序估计也只是做了1级码，一般情况是够用了，如果真有特殊字符肯定也不能正常排序。

因为要实现大字符集的拼音排序工作量太大了，而且，基本上是不可能的，Windows不可能费这么大的劲。

另：拼音排序，也可以由客户端程序自己去实现，必须你就在Qt的IconView，ListView里面实现拼音排序，整个基于Qt的所有排序都可以按照拼音去做了。

GTK也是一样的道理。

作为字符集的排序标准，可能不会按照拼音去做，因为文字最直接的表示就是字型，通过字型排序在设计的时候可行性高一些。

樱家冢

nod，习惯了，还是觉得按照拼音排序更方便。