为什么没有更多的桌面应用程序用Qt编写？

Question

据我所知，并且在我使用Qt的经验中，它是一个非常好的和容易学习的库。它有一个非常好设计的API，并且是跨平台的，而这些只是使它具有吸引力的众多特性中的两个。我很想知道为什么更多的程序员不使用Qt。是否有一种不利于它的缺陷？哪个特性使其他库比Qt更好？这问题是否与发牌有关？

Answer 1

我并不是真的希望这是一个猛烈的回答，但这是我不亲自使用Qt的原因。关于它，有很多好的方面可以说--即API大部分时间都在工作，而且它可以无缝地连接平台。但我不使用Qt，因为：

1. 在某些情况下，它看起来不像本地程序。由于各种视觉造型的原因，为所有平台设计一个单一的UI本质上是不正确的，当从一个机器移动到另一个机器。例如，在Mac机器上，分割条通常相对较厚，并且按钮很小，并且带有图标。在Windows机器上，拆分条通常是窄的，按钮更加文本化，具有更多的方形设计。仅仅因为您可以为每个平台编写一个UI，并不意味着大多数应用程序都应该这样做。
2. Qt不仅仅是一组可链接的C++库。所使用的构建系统需要将某些文件转换为额外的源文件，这使得构建过程比大多数其他库复杂得多。
3. 由于(2)，C++ IDE和工具可以将Qt表达式标记为错误，因为它们不理解Qt的具体内容。这几乎强制使用QtCreator或文本编辑器(如vim )。
4. Qt是大量的源代码，在编译之前，它必须存在并预装在您使用的任何计算机上。这可以使构建环境的设置变得更加繁琐。
5. 部件大多是在LGPL下授权的，这使得当需要在限制更严格或限制较少的许可下发布时，很难使用单二进制部署。
6. 与类似地编写“普通的本地应用程序”(当然，为KDE编写的应用程序除外)相比，它会产生非常大的编译二进制文件。

Answer 2

就像人们说的，每个工具都适合每一个问题和情况.

但是如果您是C++程序员，那么Qt就是您的框架。没有对手。

我们开发了一个复杂的医学成像商业应用程序，并坚持Qt。

我并不是说人们所说的“缺点”是错误的，但我觉得他们已经很长时间没有尝试Qt了(它在每一个新版本上都在不断改进……)而且，如果你小心的话，他们评论的大部分问题都不是问题。

UI平台的不一致性:只有当您使用UI小部件“如实”时，才能使用，没有定制或自定义艺术。

Qt预处理器过载:只有当您滥用信号插槽机制或QObject继承时，才是真正需要的。

顺便说一句，我们仍然用C#.NET编写应用程序，并且已经做了很长时间了。所以我觉得我很有预感。

就像我说的，每一种情况下的工具，

但Qt无疑是一个一致和有用的框架。

Answer 3

在我不喜欢Qt的所有东西中，它不能很好地使用模板这一事实最让我头疼。你不能这么做：

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

它也不能很好地处理预处理器。你不能这么做：

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

这与所有对信号的响应都必须是Q_OBJECT这一事实相结合，使得Qt很难为C++程序员工作。习惯于Java或Python风格编程的人实际上可能会更好。

实际上，我花费了大量的时间和精力来研究和设计一种方法来获得类型安全性，并将Qt信号连接到任何函子对象：http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1.html。

我想要做的事情是基本的、日常的C++开发，而Qt moc...which本身几乎是不可能的，如果它真的存在的话，现在是完全没有必要的。

坦率地说，我被它困住了，因为如果您想要进行自动UI测试，Qt几乎是城里唯一一个缺少MFC...which的游戏，那就是1980年(在这种糟糕的情况下工作真的很辛苦)。有些人可能会说WX，但它还有更严重的问题。GTKmm本来是我的第一选择，但由于它都是所有者绘制的，并且不具有可访问性.不能由行业标准的测试软件驱动。Qt在这方面已经够难的了(当您修改可访问性插件时几乎不起作用)。