KDE 4似乎有重大改变--KDE Plasma

baif

配置文件的问题对于*nix来说，单一的、文本的配置文件无疑是最佳的选择。当然，目前的趋势是xml的文本配置。

多做实事才是硬道理。

jin_liu

[quote:5af5821bfb="mandrakechina"][quote:5af5821bfb="jin_liu"]卷管理器(gnome-volume-manager)、可统一管理的配置文件(gconf)、计算机软件配置部署(sabayon)这些管理，windows不都有了吗，那人会喜欢吗？？[/quote]抱歉，你好象根本就不知道这些东西是干什么用的。对一个根本就不知道是什么的东西发表评论，这种做法是不对的。[/quote]
卷管理器(gnome-volume-manager)不就模仿、register吗？？看看gnome对这些东写的简介吧，一般like windows register.
晕了，这些东西有多高级？？？

jin_liu

[quote:b7e40d8290="baif"]配置文件的问题对于*nix来说，单一的、文本的配置文件无疑是最佳的选择。当然，目前的趋势是xml的文本配置。

多做实事才是硬道理。[/quote]
xml方向是对的，现在的软件配置一般都需要xml配置，至少是支持xml配置的.

cjacker

[quote:805a3416a0="jin_liu"][quote:805a3416a0="baif"]配置文件的问题对于*nix来说，单一的、文本的配置文件无疑是最佳的选择。当然，目前的趋势是xml的文本配置。

多做实事才是硬道理。[/quote]
xml方向是对的，现在的软件配置一般都需要xml配置，至少是支持xml配置的.[/quote]

个人持反对意见，我认为键值对方式是配置文件最好的选择。

理由：
1，键值对直观简洁。
2，键值对解析容易，不需要引入任何基本库(当然，如果开发者愿意，XMl也不需要)。
3，键值对方式抗破坏性强，丢几个也没有关系，XML检查性太强，丢了标签可能导致文档无法parse.
4，键值对易编辑。
......
XML是用来表意的，当然是一门非常好的技术，但是，用在配置文件上，无疑会将简单的事情复杂化。

cjacker

[quote:07a190fae1="mandrakechina"]在Qt4之前，cairo已经是可用的了。cairo可不是一个eyecandy之类的项目，它是一个地道的科学研究项目。

卷管理器(gnome-volume-manager)、可统一管理的配置文件(gconf)、计算机软件配置部署(sabayon)这些功能，都是先出现在GNOME/GTK平台上。

另外，我很反感KDE一大坨一大坨的配置对话框，有的时候经常会跑到屏幕外边去。[/quote]

配置问题是KDE/GNOME的一大分歧，KDE的观点是可以配置的都允许用户配置，GNOME的观点是能不让用户配置的尽量不让用户配置。

这一点，我个人认为GNOME作的是对的，一个kwrite,konsole就有成百上千个配置项，确实比较恐怖。



关于技术角度，个人认为两者平分秋色。
gnome-volume-manager是based on hal/dbus的，而dbus的原型就是来自于KDE的dcop。

虚拟文件系统GNOME有gnome-vfs，KDE有KIO
组件技术GNOME有bonobo，KDE有kparts。

GConf个人认为不是很好的一个实现，另外就是GNOME使用Corba我认为也不是很好的选择。


在UI绘制方面，GNOME要比KDE强一些，使用glade库，xml的ui描述文件可以在运行时载入并进行事件绑定，这一点非常的舒服。

QT/KDE的UI文件是在编译时转换成Cpp/h的。

qt4已经支持formbuilder，可以直接利用ui文件，而不需要编译时转换，但是，从语法上看，似乎比原来转换一下还要复杂了，呵呵不用也罢。


qt4新增的几个特性并没有特别让人兴奋的东西，个人认为比gtk-2.8要差一些。
(我个人的期望是能够真正的统一render Engine，做到所见即所得，但是，看目前的qt4感觉基本没有任何改善)，当然，这是需要时间的。

另外就是，其代码兼容性实在让人诟病，看来每个写qt的人又要面临一次新的代码大迁移，必然导致大量的项目因代码迁移不及时而死掉(KDE2的时候很多不错的项目就死掉了，比如kwintv，作者到现在都没有办法提供一个qt3/kde3的稳定版本，马上又要KDE4了)。不知道还有多少小软件开发者能挺得住。


gtk这一点作的确实非常的好，2.2/2.4/2.6/2.8，兼容性问题处理的实在棒极了。

sejishikong

嗯，不过QT同一个主版本内的兼容性也不错的。
gtk1到gtk2的时候也有东西要迁移的。

QT4的出现希望能对QT的软件开发有促进作用，毕竟现在是完全GPL了。windows下用也可以了。用QT写出来的跨平台程序要比wx写出来了快一些，而且QT的确做的很不错。

dukeduan

总有人说gtk的程序灰头土脸，其实每个人的审美观不尽相同，我个人就喜欢gtk的风格。

mandrakechina

corba和bonono我也觉得不是很好，但gconf还是可行的，否则kde也不会再捣鼓出来一个kcfg。况且，如果要将软件的配置进行大规模部署的话，采用INI/RC格式将是一件非常痛苦的事情。现实中，经常有设置选项的层次关系，这个是INI无法表示的。Mozilla的.js就更不必说了。

至于卷管理器，建议有些人看过gnome-volume-manager的源代码再来发表自己的意见。

cjacker

[quote:f9bde5578d="dukeduan"]总有人说gtk的程序灰头土脸，其实每个人的审美观不尽相同，我个人就喜欢gtk的风格。
[/quote]

qt4也会一样的灰头土脸

要看style能做到什么程度了。

sejishikong

[quote:30085e5b8a="mandrakechina"]corba和bonono我也觉得不是很好，但gconf还是可行的，否则kde也不会再捣鼓出来一个kcfg。况且，如果要将软件的配置进行大规模部署的话，采用INI/RC格式将是一件非常痛苦的事情。现实中，经常有设置选项的层次关系，这个是INI无法表示的。Mozilla的.js就更不必说了。

至于卷管理器，建议有些人看过gnome-volume-manager的源代码再来发表自己的意见。[/quote]

这个不用看源代码吧。对于用户来说，代码怎么样是无所谓的，即使代码写的像教科书一样，也还是要看实现了什么功能，事实上gvm实现的功能在xp下同样可以做到。虽然我看不到XP的源代码，但我能看到XP实现的功能。而且对于很多硬件来说，因为驱动的关系，XP下可能比linux下更方便。

hooey

qt3到qt4的移植如果愿意用qt3的兼容库还是很简单的，基本上没有太多的代码需要修改，不过要完全移植到qt4还要慢慢来。至于eyecandy和usability, 自从aseigo开始活跃之后就一直在讨论usability，planetkde上blog满天飞...，gnome最让我愤怒的就是把ok跟cancel的位置互换，evince据说没有打印当前页的选项(不知道现在改了没有)，不知道别的易用性怎么样。

sejishikong

ok和cancel互换的确挺那个的，不过我记得可以自己改回来吧。

cjacker

[quote:f6e83e7b1e="mandrakechina"]corba和bonono我也觉得不是很好，但gconf还是可行的，否则kde也不会再捣鼓出来一个kcfg。况且，如果要将软件的配置进行大规模部署的话，采用INI/RC格式将是一件非常痛苦的事情。现实中，经常有设置选项的层次关系，这个是INI无法表示的。Mozilla的.js就更不必说了。

至于卷管理器，建议有些人看过gnome-volume-manager的源代码再来发表自己的意见。[/quote]

gnome-volume-manager？你想说明什么问题？

他不是基于dbus/hal的？

还是看看代码吧。

rockmen

gnome-volume-manager没有DBUS/HAL根本就不能工作

mandrakechina

[quote:ccd8d95332="cjacker"][quote:ccd8d95332="mandrakechina"]至于卷管理器，建议有些人看过gnome-volume-manager的源代码再来发表自己的意见。[/quote]

gnome-volume-manager？你想说明什么问题？

他不是基于dbus/hal的？

还是看看代码吧。[/quote]我不是说你啦