gnome3基于qt，如何

[BigSnake.NET]

幻想吧。。。。

[ptptptptptpt]

偶是来学习的

[flea]

统一底层库的想法有道理，不过lz的提议就不那么可行了

[adagio]

完全不懂说个啥，不过我第一印象就喜欢gtk的咚咚，QT的很华丽，但就是不太中意
所以爱上了gnome和xfce
合并不合并没啥，我又不懂，只会用，只要别把gtk程序搞的像kde就好

[aitjcize]

xorg重寫會比較快
不然linux的圖形介面永遠比windows慢...

[cheeselee]

这个贴真雷

[fghdbs]

马屁股决定火箭助推器的宽度--路径依赖理论


一旦人們做了某種選擇，就好比走上了一條不歸之路，慣性的力量會使這一選擇不斷自我強化，並讓你不能輕易走出去。


在現實生活中，路徑依賴現象無處不在。一個著名的例子是：現代鐵路兩條鐵軌之間的標準距離是四英尺又八點五英寸，為什麼採用這個標準呢？原來，早期的鐵路是由建電車的人所設計的，而四英尺又八點五英寸正是電車所用的輪距標準。那麼，電車的標準又是從哪裡來的呢？最先造電車的人以前是造馬車的，所以電車的標準是沿用馬車的輪距標準。馬車又為什麼要用這個輪距標準呢？因為古羅馬人軍隊戰車的寬度就是四英尺又八點五英寸。羅馬人為什麼以四英尺又八點五英寸為戰車的輪距寬度呢？原因很簡單，這是牽引一輛戰車的兩匹馬屁股的寬度。
　　有趣的是，美國太空梭燃料箱的兩旁有兩個火箭推進器，因為這些推進器造好之後要用火車運送，路上又要通過一些隧道，而這些隧道的寬度只比火車軌道寬一點，因此火箭助推器的寬度由鐵軌的寬度所決定。所以，今天世界上最先進的運輸系統的設計，在兩千年前便由兩匹馬的屁股寬度決定了！
　　人們關於習慣的一切理論都可以用“路徑依賴”來解釋。它告訴我們，要想路徑依賴的負面效應不發生，那麼在最開始的時候就要找準一個正確的方向。每個人都有自己的基本思維模式，這種模式很大程度上會決定你以後的人生道路。而這種模式的基礎，其實是早在童年時期就奠定了的。做好了你的第一次選擇，你就設定了自己的人生。

[linooxlee]

其实kde基于gtk也是可以的，关键是桌面图形库底层要统一。以现在情况来看，gome3基于qt比较好，毕竟qt4.5和kde4已经走在前面了，而gnome3还没个影子。

[三翻领]

其实kde基于gtk也是可以的，关键是桌面图形库底层要统一。以现在情况来看，gome3基于qt比较好，毕竟qt4.5和kde4已经走在前面了，而gnome3还没个影子。

整个帖子，这个回复最有水平

[幽隐之贤]

挖個尸，看到這個了就有些話要說了。前面說Qt沒有C綁定。不是沒有，而是沒有必要。網上有一堆Mixing C and C++ code的教程。寫個C綁定比寫其它的綁定都方便。extern "C"一下，什麽都解決了。但是有心思去搞這個的人大多都願意去遷就C++了。

[ciclo]

不喜欢kde软件的界面风格，所以不喜欢qt

[delectate]

其实kde基于gtk也是可以的，关键是桌面图形库底层要统一。以现在情况来看，gome3基于qt比较好，毕竟qt4.5和kde4已经走在前面了，而gnome3还没个影子。

慢慢来

ps：如果真的gnome基于qt，我就用ReactOS去！

或者韩国那个什么windows

[adam8157]

挖個尸，看到這個了就有些話要說了。前面說Qt沒有C綁定。不是沒有，而是沒有必要。網上有一堆Mixing C and C++ code的教程。寫個C綁定比寫其它的綁定都方便。extern "C"一下，什麽都解決了。但是有心思去搞這個的【被屏蔽】多都願意去遷就C++了。

不是没有必要 是确实没有 不可能用C完全绑定qt 因为qt面向对象 高级的多 反过来 gtk就有C＋＋的绑定（GTKMM）

而我 就是一个不愿碰C＋＋的 宁愿用pyqt 可惜非lgpl

[mir_lww]

我也来挖尸。。。
个人不太执着于gtk，也不讨厌qt。只是比较喜欢gtk的界面，也已经习惯了gnome，而它也比较稳定。

当然到现在为止.还没有那个桌面发展到能和KDE相比的. 楼下的同学表跟我说gnome.因为gnome只提供了基础得不能再基础的功能.

喜欢kde不一定要抬高kde贬低gnome，这样做除了满足自己外，对讨论毫无贡献。

首先承认，kde4相比kde3是一个巨大的进步，在gnome下用qt4的程序的确快了很多，但感觉不出 “qt性能强大”。

用qt4写的软件也不乏精品，smplayer比gmplayer好n倍，qt4版本的k3b我也十分期待，VirtuanBox的gui也是qt4的。反正那个软件好用就用那个。

kde走的是华丽精致路线而Gnome则是简洁朴实路线

kde4的默认主题算是精致，但我不怎么喜欢。Gnome的默认主题确实比较朴实，不过主题可以设置。一样可以做到“华丽精致”

kde4已经完成了新一代的消息通讯、多媒体支持等底层构架

如果可以上升到freedesktop的标准，值得讨论。

说到底，qt、gtk、C、C++等只是个工具

同意，理想的情况下，应该是设计者自由选择，然后使用者察觉不到程序是用qt还是gtk写的。

gtk/Gnome的成功（与其说是技术成功，不如说更多的是它的GPL许可证策略的成功）

X86的成功有人也说是市场的成功，windowns的成功也是市场的成功，但成功就是成功。

gtk技术相对落后

不见得，感觉不到qt4写的程序比gtk快多少。

但各桌面环境的底层库各不相同在技术上对linux桌面进行了割裂，这给用户和第三方应用软件开发者带来了不便

但竞争的另外一方面是加快了双方的发展，我可不想见到只有一个cpu厂商，一个显卡厂商，然后是一个os厂商。。。

综上，比较可行的是Gnome和KDE共同推动Freedesktop标准，然后各自实现。

[幽隐之贤]

挖個尸，看到這個了就有些話要說了。前面說Qt沒有C綁定。不是沒有，而是沒有必要。網上有一堆Mixing C and C++ code的教程。寫個C綁定比寫其它的綁定都方便。extern "C"一下，什麽都解決了。但是有心思去搞這個的【被屏蔽】多都願意去遷就C++了。

不是没有必要 是确实没有 不可能用C完全绑定qt 因为qt面向对象 高级的多 反过来 gtk就有C＋＋的绑定（GTKMM）

而我 就是一个不愿碰C＋＋的 宁愿用pyqt 可惜非lgpl

可以完全使用C來綁定Qt的。你可以在網上找一下很早以前的QtC-bindings。寫到0.0.2的時候因為沒有人用所以作者不寫了。
　　即使是面向對象，C也可以勝任。即使是現在還保留著C++的程序改成C程序再編譯的編譯手段。如果C++不能和C有對等的處理，那現在那些C++都不編譯了？有時間這位網友或者其它對於C bindings有懷疑看法的網友可以看下sun developers網站上的mixing c and c++ code in the same programmes這篇文章和gcc-on-cxx項目的討論。前者提供了標準c++中與標準C中不同內容的對應的處理方案，後者的lwn討論中有更詳細的信息，比如虛函數和模板在C當中的等價處理。