Igo*_*Oks 18 user-interface qt cross-platform eclipse-rcp
我将为现有的C++应用程序开发一个新的GUI.该应用程序适用于Windows和Linux,与GUI的通信是通过客户端/服务器进行的.
Eclipse RCP和Qt之间的优缺点是什么?
nca*_*sas 24
Eclipse RCP不仅仅是一个图形工具包:
您可以在应用程序中使用许多Eclipse插件,其中许多插件具有对商业产品友好的分发许可证.
它有一个WYSIWYG设计师.
Eclipse使用一个名为SWT的自定义窗口工具包; 在每个平台上,它依赖于本机图形层.在Linux上,它依赖于Gtk +(虽然它也可以使用Motif),根据我的经验(和其他),它有性能问题,主要是使用高速更新的小部件.实际上,我们中的许多人在Eclipse RCP应用程序中嵌入了Swing元素,以克服性能问题,同时保持Eclipse的可扩展体系结构; 但是,这会带来集成问题.有一个版本的SWT使用Qt作为后端,但是它自2010年10月以来停滞在Eclipse的代码库中似乎停滞不前.
Eclipse RCP应用程序的启动时间(理解为自应用程序启动以来直到它显示窗口所经过的时间)可能非常长.
Eclipse有很多错误.Eclipse的bugzilla对于RCP开发人员来说是一个非常有用的资源.
您希望Eclipse RCP应用程序的外观和行为与Eclipse IDE不同,您将遇到的麻烦越多.
在我看来,Eclipse RCP开发有一个很大的学习曲线.
将Eclipse RCP用于小型项目基本上是一种自杀(除非你限制自己只创建一个插件或类似的).由于其基础设施的复杂性,资源需求和上述陡峭的学习曲线,它适用于中型到大型和非常大的项目.
在我看来,他们的发行许可证(用于Qt的LGPL/GPL /商业版,用于Eclipse的EPL)对于大多数用途来说足够灵活.然而,我不是律师,所以我可能会误解为此.
当然,还应考虑其他因素,如开发人员的经验,他们的技术技能,团队规模,具体要求等.
顺便说一句,我在Eclipse RCP方面有很多经验,但只有Qt的理论知识,所以我的陈述可能有偏见/错误.
Liz*_*Liz 10
既然Qt拥有LGPL许可证,我会选择Qt,而不是Eclipse RCP.
我用它们来创建相当复杂的应用程序.
既然你可以使用eclipse来开发c ++,我假设我们主要是比较swt/jface和Qt,而不是eclipse开发环境本身.
我注意到的一些事情都使用过:
1)Qt有更好的文档和样本
除了网上的一些半生不熟的例子,我还能找到一些有用的eclipse文档.
2)Qt拥有更多"专业"用户
有许多专业公司使用Qt作为他们的UI框架.鉴于它有三个平台支持(Windows,Linux,Mac),它非常灵活,并且有很多支持.
3)Qt往往更完整和成熟 -
使用Eclipse我注意到,通常控件和可用的包只是部分完成,并不完全.它们通常是为某人使用而开发的,并且只编码.Qt的控件几乎总是一个完整的设计.
4)造型.
Qt和Eclipse都使用本地平台库进行渲染,因此您的UI将"看起来"像您正在运行的平台上的其他UI(即Linux与Windows).但是,Qt还提供了相当复杂的样式功能,使您可以轻松地更改任何控件的外观,并使您可以更好地控制应用程序的外观.
使用新的声明性语言(Qt 4.7.*),您正在接近WPF控制级别,这真是太棒了.
5)UI设计师:
Qt有一个更丰富的Designer,允许您布局表单,并进行基本测试而无需编译任何代码.设计器还使您能够在表单上的控件之间添加交互.防爆.单击此按钮 - 禁用此选项
Eclipse也有一个表单设计器,尽管我对它的体验有限.我确实尝试使用它几次,但成功非常有限.最后,我通过代码手动编写了每个表单.那很痛苦.
6)与现有源代码连接
如果你没有这个问题,那么你很幸运.因为Qt是基于c ++的,所以它可以与传统的C和C++代码无缝集成.集成Java和C并不容易.
7)绘制图书馆
我尝试使用swt库编写一些手绘形状,并被迫绕过swt绘图库的大部分,因为那里有污泥.使用Qt做类似的事情完全没有问题.
8)树和列表模型
Eclipse确实提供了一些很好的开箱即用功能,可以将传播的数据传输到树,列表和事物中.它在Qt中几乎一样好,虽然设置起来有点棘手.
9)应用程序布局
Eclipse提供了一些很好的功能来管理"视图"(停靠面板)和"透视图"(工作流),如果您决定使用它们,那么生活将变得简单易行.Qt要求你自己这样做.Qt确实有停靠面板功能,但是在构建丰富的应用程序时,您必须自己设置它.
额外注意:
Qt还提供了一些额外的库来支持xml等等......所以这有助于弥补c ++和java之间的差距.