Eclipse/RCP (SWT) 与 Qt Creator (Qt) 作为插件开发框架?

发布于 2024-09-06 01:56:53 字数 255 浏览 5 评论 0原文

我知道许多优秀的应用程序(包括 UG Team Center、IBM Lotus Expeditor 等)都是通过 Eclipse(RCP Framework)开发的。最近,我发现一些通过 Qt Creator 开发的应用程序利用其插件架构(GCF、VTK 设计器等)。

我希望了解 Eclipse 和 Qt Creator 作为开发应用程序的基础框架的优缺点。另外,如果有人可以列出支持每个框架中的应用程序的模块。您推荐哪一款用于跨平台应用程序开发?

非常感谢。

I have known many good applications (including UG Team Center, IBM Lotus Expeditor etc.,) developed over Eclipse (RCP Framework). Of late, i find some application developed over Qt Creator exploiting its plug-in architecture (GCF, VTK designer etc.,).

I wish to know the pros and cons of Eclipse and Qt Creator as base framework for developing applications over it. Also if someone can list down the modules that support the applications in each of these framework. Which one do you recommend for a cross-platform application development?

many thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

最舍不得你 2024-09-13 01:56:53

免责声明:我对 Creator 进行了修改,

我认为 Creator 和 Eclipse 都是稳定且功能齐全的 IDE。 Creator 重点关注 C++ 和 Quick(Qt 领域的新事物;-),而 Eclipse 支持一整套语言,其中 Java 支持非常出色。这当然也会影响您的插件可以轻松提供的功能。

对于插件开发人员来说,第一个明显的区别当然是编程语言:Eclipse 是用 Java 编写的,而 Creator 是使用 C++ 和 Qt 开发的。根据您的开发背景,这可能非常重要。

两者都提供了一个不错的插件系统,具有所有主要功能,例如处理插件之间的依赖关系、版本控制等。我想 Eclipse 的插件系统现在更加“久经沙场”,因为它们还有很多第三方插件那就是不断地“测试”它。这两个项目都有一些仍在开发中的 API(我的印象是,目前 Eclipse 的问题较少),因此值得检查路线图。

Eclipse 往往有更多可用的插件,如果您的插件可以从其他插件中已实现的功能中受益,这可能是一个优势。这里我想到了图形建模等。 Creator 还没有那么多插件,但是有很多基于 Qt 的开源代码可用,这些代码应该可以直接移植到插件中(如果许可允许的话!)。

这两个项目都是开源的,因此您可以查看代码。 Qt Creator 和 Eclipse 的许可证不同。如果您考虑为其中任何一个做一个专有插件,最好让律师阅读它们......但这只是标准建议:-) 这

两个项目都有欢迎的用户社区,他们愿意在遇到困难时提供帮助,并且两个项目都接受代码贡献(如果您不想自己一直更新代码;-)。

这是我脑子里能想到的……

Disclaimer: I hack on creator

I consider both creator and Eclipse to be stable and pretty full-featured IDEs. Creator is focusing heavily on C++ and Quick (the new bling thing in Qt land;-) while Eclipse supports a whole host of languages, with its Java support really shining. This of course does also influence the functionality your plugin can easily provide.

The first visible difference to a plugin developer is of course the programming language: Eclipse is written in Java while creator is developed using C++ with Qt. Depending on your development background that can be pretty significant.

Both provide a decent plugin system with all the mayor functionality like handling dependencies between plugins, versioning, etc. I guess the plugin system of Eclipse is a bit more "battle-hardened" by now, since they have quite a few more 3rd party plugins that is constantly "testing" it. Both projects have some APIs that are still developing (my impression is that this less of an issue with eclipse at this time), so it is worth checking the roadmaps.

Eclipse tends to have more plugins available and this can be an advantage if your plugin can benefit from functionality already implemented in other plugins. Graphic modeling, etc springs to mind here. Creator does not have that many plugins yet, but there is lots of Qt-based open-source code available which should be straight forward to port into plugins (if the licensing permits this!).

Both projects are open source, so you can view the code. The license is different though Qt Creator and Eclipse. Better get a lawyer to read over them if you consider doing a proprietary plugin for either of them... but that is just standard advice:-)

Both project have welcoming user communities that are willing to help when getting stuck and both projects accept code contributions (in case you do not want to keep updating your code yourself all the time;-).

That is what I can think about at the top of my head...

提笔落墨 2024-09-13 01:56:53

最初我是 QtCreator 的忠实粉丝。然后我发现它让我摆脱了许多我不应该做的程序化的事情。我一下子记不清了,但是当我移植到 Mac OSX 时,我决定在 XCode 而不是 QtCreator 中构建它。在构建过程中,我发现了许多我从未见过的错误。

...我知道这是正常运行的代码...

无论如何,我仍然在 Qt 中工作很多并且非常喜欢它,但我在 Visual Studio、XCode 和 GCC 各自的平台上进行开发。抱歉,我不记得任何例子了,6 个月前我遇到了这个问题。

Initially I was a huge fan of QtCreator. Then I discovered that it was letting me get away with many programmatic things that I shouldn't have. I can't remember any off the top of my head, but when I ported to Mac OSX I decided to build it in XCode rather than QtCreator. Upon my build, I discovered a load of errors that I had never seen.

...And I had known this as normally functioning code...

Anyways, I still work in Qt a lot and thoroughly enjoy it, but I develop in Visual Studio, XCode, and GCC on their respective platforms. Sorry that I can't remember any examples, I ran into this problem 6 months ago.

玻璃人 2024-09-13 01:56:53

Eclipse 更多的是基于 Java 的,Qt 是 C++ 的,还有一些有用的补充(信号+槽等)。我从未听说过 Eclipse 作为一个框架,但这当然并不是支持或反对它。我将在这里表达我对 Qt 的想法:

我坚信 Qt 作为基础,因为它(它的开发人员)拥有多年的经验,提供了一个良好的跨平台框架,几乎包含了您需要的一切。它有网络、文件系统、图形用户界面、算法、容器、翻译工具、UI 设计器、非常好的文档和坚实的社区。它基于 C++,这使得与几乎任何 C 或 C++ 库的交互变得“轻而易举”。 Qt 是迄今为止更成熟的玩家。

Eclipse is more an Java-based, Qt is C++ and some helpful additions (signals+slots among others). I've never heard of Eclipse as a framework, but that of course does not speak for or against it. I'll give my thoughts on Qt here:

I believe strongly in Qt as a base, because it (its devs) has had years of experience providing a good cross-platform framework with pretty much everything you'll ever need. It has network, file system, gui, algorithms, containers, translation tools, UI designer, VERY good documentation, and a solid community. It is C++ based, which makes interaction with pretty much any C or C++ library "a breeze". Qt is by far the more mature player here.

时间你老了 2024-09-13 01:56:53

注意:我在两者上进行开发,我在 Java 博客 上分享我的经验,Qt 博客诺基亚论坛博客。我也是诺基亚论坛冠军

简单的答案是Eclipse RCP

不久前在这里发表了有关跨平台桌面框架的博客,包括 Eclipse RCP 与 Qt Creator 与其他框架。

Eclipse RCP 不仅仅适用于复杂的应用程序。使用 Eclipse RCP 进行开发非常容易上手。获取一本关于 Eclipse RCP 的好书,我推荐这本书。而且您几乎没有平台障碍。对长远发展是有好处的。根据我个人的经验,Eclipse RCP 应用程序(以及就此而言精心设计的 Java 应用程序)的可维护性比 Qt 应用程序要好得多。

我建议的 Eclipse RCP 的“扩展”是 EMF。尽管 EMF 非常复杂,但最简单的方法是使用它来设计元模型并从中生成 Java 类。您还可以在 RCP UI 中轻松编辑对象(在 Web 应用程序世界中,“CRUD”部分)。这是一本关于 EMF 的实用书籍

Eclipse 生态系统非常广泛,一开始可能会令人困惑,但诀窍是专注于手头的任务。当您对基本内容充满信心后(这相对容易,您只需启动向导或按照提供的教程即可运行您的第一个 hello world RCP 插件/应用程序),Eclipse 社区中的大量工具和选项只是惊人的。 (大多数 Eclipse 项目都是成熟/稳定的,其中一些项目需要耐心甚至贡献,但这就是开源社区的美妙之处)

请注意,我对 Qt 没什么好说的。 Qt 是一个优秀框架,具有 Qt Quick 和 QML 以及移动支持。如果您要实现这些目的,最好使用它。除非您确实需要 Qt,否则 Eclipse RCP 应该会让您的生活更轻松。

Note: I develop on both, I share my experiences on a Java blog, Qt blog, and Forum Nokia blog. I'm also a Forum Nokia Champion.

The simple answer is Eclipse RCP.

I blogged about cross-platform desktop frameworks sometime ago here, including Eclipse RCP vs Qt Creator vs other frameworks.

Eclipse RCP is not just for complex applications. Developing with Eclipse RCP is very easy to get started. Get a good book for Eclipse RCP, I recommend this one. And you practically have no platform barriers. It's good for long term development. In my personal experience, maintainability for Eclipse RCP apps (and well designed Java apps for that matter) is much better than a Qt app.

An "extension" to Eclipse RCP that I suggest is EMF. Although EMF is very complex, the easiest path is using it to design metamodels and generate Java classes from it. You'll also be able to edit your objects easily in RCP UI (in web apps world, the "CRUD" part). Here's a good practical book on EMF.

Eclipse ecosystem is very broad, and it may be confusing at first, but the trick is to focus on the task at hand. After you're confident with the basic stuff (which is relatively easy, you can run your first hello world RCP plugin/app just by starting a wizard or following the provided tutorial), the plethora of tools and options in the Eclipse community is just awesome. (most of the Eclipse projects are mature/stable, some of them require patience or even contribution, but that's the beauty of the open source community)

Note that I have nothing bad to say about Qt. Qt is an excellent framework, with Qt Quick and QML and mobile support. And it's best used if you're on to those purposes. Unless you actually require Qt, Eclipse RCP should make your life easier.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文