问题描述
我写的很多，我有点困惑，但如果我没有弄错，Canonical正在用Qt为移动设备构建下一代Unity，并且在不久的将来桌面也将迁移到qt。
我只是想知道推动这一决定的技术和/或政治原因，以及它对当前现有的Ubuntu桌面应用程序意味着什么。
最佳解决思路
您可以在邮件列表和Mark Shuttleworth’s blog上找到答案。这篇博文可能最好回答：
As part of our planning for Natty+1, we’ll need to find some space on the CD for Qt libraries, and we will evaluate applications developed with Qt for inclusion on the CD and default install of Ubuntu.
Ease of use, and effective integration, are key values in our user experience. We care that the applications we choose are harmonious with one another and the system as a whole. Historically, that has meant that we’ve given very strong preference to applications written using Gtk, because a certain amount of harmony comes by default from the use of the same developer toolkit. That said, with OpenOffice and Firefox having been there from the start, Gtk is clearly not an absolute requirement. What I’m arguing now is that it’s the values which are important, and the toolkit is only a means to that end. We should evaluate apps on the basis of how well they meet the requirement, not prejudice them on the basis of technical choices made by the developer.
In evaluating an app for the Ubuntu default install, we should ask:
- is it free software?
- is it best-in-class?
- does it integrate with the system settings and preferences?
- does it integrate with other applications?
- is it accessible to people who cannot use a mouse, or keyboard?
- does it look and feel consistent with the rest of the system?
Of course, the developer’s choice of Qt has no influence on the first two. Qt itself has been available under the GPL for a long time, and more recently became available under the LGPL. And there’s plenty of best-in-class software written with Qt, it’s a very capable toolkit.
System settings and prefs, however, have long been a cause of friction between Qt and Gtk. Integration with system settings and preferences is critical to the sense of an application “belonging” on the system. It affects the ability to manage that application using the same tools one uses to manage all the other applications, and the sorts of settings-and-preference experience that users can have with the app. This has traditionally been a problem with Qt / KDE applications on Ubuntu, because Gtk apps all use a centrally-manageable preferences store, and KDE apps do things differently.
To address this, Canonical is driving the development of dconf bindings for Qt, so that it is possible to write a Qt app that uses the same settings framework as everything else in Ubuntu. We’ve contracted with Ryan Lortie, who obviously knows dconf very well, and he’ll work with some folks at Canonical who have been using Qt for custom development work for customers. We’re confident the result will be natural for Qt developers, and a complete expression of dconf’s semantics and style.
The Qt team have long worked well in the broader Ubuntu community – we have great Qt representation at UDS every six months, the Kubuntu team have deep experience and interest in Qt packaging and maintenance, there is lots of good technical exchange between Qt upstream and various parts of the Ubuntu community, including Canonical. For example, Qt folks are working to integrate uTouch.
I’d draw a distinction between “Qt” and “KDE” in the obvious places. A KDE app doesn’t know anything about the dconf system configuration, and can’t easily integrate with the Ubuntu desktop as a result. So we’re not going to be proposing Amarok to replace Banshee any time soon! But I think it’s entirely plausible that dconf, once it has great Qt bindings, be considered by the KDE community. There are better people to lead that conversation if they want, so I’ll not push the idea further here . Nevertheless, should a KDE app learn to talk dconf in addition to the standard KDE mechanisms, which should be straightforward, it would be a candidate for the Ubuntu default install.
The decision to be open to Qt is in no way a criticism of GNOME. It’s a celebration of free software’s diversity and complexity. Those values of ease of use and integration remain shared values with GNOME, and a great basis for collaboration with GNOME developers and project members. Perhaps GNOME itself will embrace Qt, perhaps not, but if it does then our willingness to blaze this trail would be a contribution in leadership. It’s much easier to make a vibrant ecosystem if you accept a certain amount of divergence from the canonical way, so to speak Our work on design is centered around GNOME, with settings and preferences the current focus as we move to GNOME 3.0 and gtk3.
Of course, this is a perfect opportunity for those who would poke fun at that relationship to do so, but in my view what matters most is the solid relationship we have with people who actually write applications under the GNOME banner. We want to be the very best way to make the hard work of those free software developers matter, by which we mean, the best way to ensure it makes a real difference in millions of lives every day, and the best way to connect them to their users.
To the good folks at Trolltech, now Nokia, who have made Qt a great toolkit – thank you. To developers who wish to use it and be part of the Ubuntu experience – welcome.
次佳解决思路
GTK +不支持分辨率独立性，现代移动设备具有超高像素密度。如果您在移动屏幕上运行GTK +应用程序，则所有用户界面元素都会非常小而无法使用。
这是自2008年以来一直是an open bug on GTK+直到它在2014年关闭，“我们现在有hi-dpi规模支持 – 它不是完全相同的东西，但足够接近使这个bug过时”评论。
当GTK + 3发布时，该项目提供了增加分辨率独立性的绝佳机会，因为它们无论如何都在破坏兼容性。他们选择不这样做，现在对他们来说真的太晚了。
在GTK+ Roadmap上，计划在4.0之后的版本中进行解析独立性，因此它们将发布4.0然后在主要版本之后才会发布。如果他们坚持这个计划，那么即使桌面GNU /Linux也不得不放弃GTK +，因为高DPI桌面显示器和笔记本电脑显示器已经可用并且即将成为新常态。
第三种解决思路
我对技术/实用理由的看法：诺基亚收购了奇趣科技，并在QT上投入了大量资金。它轻巧，并且在移动平台上有多年的优化。无论您目前对诺基亚的看法如何，N900都比它的时间早了几年……它是基于debian /QT的…而且价格昂贵。但是，我对这些决定并不了解。