配置文件的问题对于*nix来说，单一的、文本的配置文件无疑是最佳的选择。当然，目前的趋势是xml的文本配置。
多做实事才是硬道理。
卷管理器(gnome-volume-manager)、可统一管理的配置文件(gconf)、计算机软件配置部署(sabayon)这些管理，windows不都有了吗，那人会喜欢吗？？抱歉，你好象根本就不知道这些东西是干什么用的。对一个根本就不知道是什么的东西发表评论，这种做法是不对的。
卷管理器(gnome-volume-manager)不就模仿、register吗？？看看gnome对这些东写的简介吧，一般like windows register.
晕了，这些东西有多高级？？？
配置文件的问题对于*nix来说，单一的、文本的配置文件无疑是最佳的选择。当然，目前的趋势是xml的文本配置。
多做实事才是硬道理。
xml方向是对的，现在的软件配置一般都需要xml配置，至少是支持xml配置的.
配置文件的问题对于*nix来说，单一的、文本的配置文件无疑是最佳的选择。当然，目前的趋势是xml的文本配置。
多做实事才是硬道理。
xml方向是对的，现在的软件配置一般都需要xml配置，至少是支持xml配置的.
个人持反对意见，我认为键值对方式是配置文件最好的选择。
理由：
1，键值对直观简洁。
2，键值对解析容易，不需要引入任何基本库(当然，如果开发者愿意，XMl也不需要)。
3，键值对方式抗破坏性强，丢几个也没有关系，XML检查性太强，丢了标签可能导致文档无法parse.
4，键值对易编辑。
......
XML是用来表意的，当然是一门非常好的技术，但是，用在配置文件上，无疑会将简单的事情复杂化。
在Qt4之前，cairo已经是可用的了。cairo可不是一个eyecandy之类的项目，它是一个地道的科学研究项目。
卷管理器(gnome-volume-manager)、可统一管理的配置文件(gconf)、计算机软件配置部署(sabayon)这些功能，都是先出现在GNOME/GTK平台上。
另外，我很反感KDE一大坨一大坨的配置对话框，有的时候经常会跑到屏幕外边去。
配置问题是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，兼容性问题处理的实在棒极了。
嗯，不过QT同一个主版本内的兼容性也不错的。
gtk1到gtk2的时候也有东西要迁移的。
QT4的出现希望能对QT的软件开发有促进作用，毕竟现在是完全GPL了。windows下用也可以了。用QT写出来的跨平台程序要比wx写出来了快一些，而且QT的确做的很不错。
总有人说gtk的程序灰头土脸，其实每个人的审美观不尽相同，我个人就喜欢gtk的风格。
8)
corba和bonono我也觉得不是很好，但gconf还是可行的，否则kde也不会再捣鼓出来一个kcfg。况且，如果要将软件的配置进行大规模部署的话，采用INI/RC格式将是一件非常痛苦的事情。现实中，经常有设置选项的层次关系，这个是INI无法表示的。Mozilla的.js就更不必说了。
至于卷管理器，建议有些人看过gnome-volume-manager的源代码再来发表自己的意见。
总有人说gtk的程序灰头土脸，其实每个人的审美观不尽相同，我个人就喜欢gtk的风格。
8)
qt4也会一样的灰头土脸:-D
要看style能做到什么程度了。
corba和bonono我也觉得不是很好，但gconf还是可行的，否则kde也不会再捣鼓出来一个kcfg。况且，如果要将软件的配置进行大规模部署的话，采用INI/RC格式将是一件非常痛苦的事情。现实中，经常有设置选项的层次关系，这个是INI无法表示的。Mozilla的.js就更不必说了。
至于卷管理器，建议有些人看过gnome-volume-manager的源代码再来发表自己的意见。
这个不用看源代码吧。对于用户来说，代码怎么样是无所谓的，即使代码写的像教科书一样，也还是要看实现了什么功能，事实上gvm实现的功能在xp下同样可以做到。虽然我看不到XP的源代码，但我能看到XP实现的功能。而且对于很多硬件来说，因为驱动的关系，XP下可能比linux下更方便。
qt3到qt4的移植如果愿意用qt3的兼容库还是很简单的，基本上没有太多的代码需要修改，不过要完全移植到qt4还要慢慢来。至于eyecandy和usability, 自从aseigo开始活跃之后就一直在讨论usability，planetkde上blog满天飞...，gnome最让我愤怒的就是把ok跟cancel的位置互换，evince据说没有打印当前页的选项(不知道现在改了没有)，不知道别的易用性怎么样。
ok和cancel互换的确挺那个的，不过我记得可以自己改回来吧。
corba和bonono我也觉得不是很好，但gconf还是可行的，否则kde也不会再捣鼓出来一个kcfg。况且，如果要将软件的配置进行大规模部署的话，采用INI/RC格式将是一件非常痛苦的事情。现实中，经常有设置选项的层次关系，这个是INI无法表示的。Mozilla的.js就更不必说了。
至于卷管理器，建议有些人看过gnome-volume-manager的源代码再来发表自己的意见。
gnome-volume-manager？你想说明什么问题？
他不是基于dbus/hal的？
还是看看代码吧。
gnome-volume-manager没有DBUS/HAL根本就不能工作
至于卷管理器，建议有些人看过gnome-volume-manager的源代码再来发表自己的意见。
gnome-volume-manager？你想说明什么问题？
他不是基于dbus/hal的？
还是看看代码吧。我不是说你啦 :mrgreen: