有关 gtk1 的讨论热火朝天
虽然一直在向这个方向努力, 他们都不敢走出最后一步
xmms 已经被移动到了 extras
gnome-vfs1 被去掉了
只有 gnucash 和 gtk1, glib1 几个库了吧
我赞同将 gtk1 移动到 extras 因为配置中文太困难了. 另外, 将所有中文支持得不好的程序都移到 extras 里面, 包括 xpdf, tk, emacs 等等
I care about the apps. And that means being biased against anything
which can't display languages other than English (or just Western
European languages.) Since essentially everything using gtk+ works
poorly with multiple charsets, that's a bias against gtk+.
Internationalization is *hard* with gtk+. CJK support and complex rendering
language support requires thinking in all sorts of ways that programmers who
speak only Western European languages don't usually. gtk2, pango, and
fontconfig make it almost automatic. So I don't think I'm too crazy here.
John Thacker
That was filelists.xml for development -- 36MB of XML, not
primary.xml. There was a 2.5 times speed improvement with cElementTree
code, compared to old yum code, using libxml2 -- around 20 seconds for
libxml2, and around 7-8 seconds for cElementTree on an AMD Athlon
2600+.
Regards,
--
Konstantin Ryabitsev
Zlotniks, INC
> it's not libxml2. you will see that libxml2 by itself on such a
> box should parse your 36MB of XML in a mere second. Try with xmllint --stream
> for example. The potential for improvements by solving the python string
> import would have been huge if you did want to look at it, but it seems
> obvious you didn't want.
>
Daniel,
But we're not talking about libxml2 in C, we're talking about using it
in python. I agree with you, we could have worked on the python string
handling and it's interface to libxml2. But time is not free and Icon
nor I had the inclination to work on it. Icon saw elementTree, it proved
to do the same job and do it fairly well. It was low-hanging fruit.
If you or anyone else would like to implement the functions in libxml2
and make the import work just as quickly and the api look just as pretty
and I'll be glad to take a look at the results. But I just don't have
the time to do it. Remember, some of us are volunteers.
-sv