Stephan Sokolow (他/他的)

201 积分
User profile image.
安大略省,加拿大

Stephan 对软件自由、人机交互、用户界面/体验设计、编程和 Linux 感兴趣...但他更喜欢将平面设计留给专家。

撰写的评论

更多通用代码肯定有意义,但有很多原因使其难以实现。

我的理解是,在它们最具形成性的几年里,KDE 通常首先提出解决方案,然后 GNOME 重新发明,因为他们不愿意在他们对 Qt 的自定义预处理 C++ 方言以及旧版本 GCC 编译的 C++ 的性能不佳上让步。(这假设你只计算 Qt 的 Linux 版本获得 GPL 兼容许可证之后的东西)

这发展成为一个通用规则,即用 C 而不是 C++ 编写 GNOME 的核心。显然,D-Bus 基本上是 DCOP(如果我没记错的话,最早在 KDE 2 中引入),经过重新设计并用 C 重写,最终使 GNOME 加入。

我还听说,至少有时,KDE 拒绝使用 GNOME 原始库,仅仅是因为他们认为代码质量太差,或者重新发明这些功能太费力。(虽然这不是一个破坏交易的例子,但当 GTK+ 获得在 OpenGL 画布中放置小部件的支持时,人们大肆宣传。Qt 在几个月前就支持了<strong>带有</strong>输入转换的功能。)

此外,我见过很多例子,GNOME 项目内部或周围的各种个人开发者根本不是你想依赖的那种人。

我知道,当涉及到 GStreamer 时,KDE 实际上<em>确实</em>使用了它,但是,当版本升级(我认为是 0.6 到 0.8)更改了 API,足以使他们的薄包装器无用时,他们编写了 Phonon,它足够厚,可以允许运行时交换 GStreamer、Xine、QuickTime、DirectMedia 等。(以确保他们可以在整个 4.x 周期内冻结 KDE 平台库的 API)作为回应,至少一位 GStreamer 作者发脾气。

基本上,基于 Qt 和基于 GTK 的库生态系统由于其历史和社区已经积累了如此大的惯性,以至于需要付出巨大的努力才能朝着重新统一底层基础设施迈出任何真正意义重大的步骤。(特别是由于 Qt 和 GTK+ 以不同方式实现的事件循环、信号/槽系统等等,对于现有应用程序和库的结构至关重要。)

我在同一台机器上安装了 GNOME3 和 LXDE。我曾让那些信誓旦旦地支持 GNOME3 的人确认性能和响应能力应该如此……我太习惯 LXDE 了,以至于相比之下 GNOME3 感觉慢得难以忍受。

也许是因为我重视诸如从单击启动器到在 500 毫秒或更短的时间内完全加载并可用的文件管理器窗口而没有进一步的加载延迟之类的事情。

至于“高级用户”与“调整者”,我真的很好奇你如何为 GNOME 继续删除有用的功能(例如 Nautilus 中的紧凑视图和树形侧边栏)以追逐一些不切实际的 GNOME-on-平板电脑愿景辩护。

© . All rights reserved.