Why Qt?

Forum for support and development discussion regarding the python based unified editor tool for CEGUI, known as CEED.

Moderators: CEGUI MVP, CEGUI Team

Marc Horstmann
Just popping in
Just popping in
Posts: 1
Joined: Tue Nov 10, 2015 13:08

Why Qt?

Postby Marc Horstmann » Tue Nov 10, 2015 13:17

CEED is build with Qt. What was the reason behind that decision?

Why not using CEGUI for that?

Posts: 448
Joined: Fri Jun 19, 2015 12:18
Location: Kiryat-Bialik, Israel

Re: Why Qt?

Postby YaronCT » Tue Nov 10, 2015 13:21

Doesn't Qt use CEGUI for Qt Creator? :wink:

User avatar
Posts: 1870
Joined: Sat Oct 31, 2009 13:57
Location: Austria

Re: Why Qt?

Postby Ident » Thu Nov 12, 2015 21:30

Marc Horstmann wrote:CEED is build with Qt. What was the reason behind that decision?

Why not using CEGUI for that?

CEGUI is made primarily for rendering and handling e.g. HUDs, UI elements, menus and dialogs in real-time application, mostly games, rendering, visualisation, etc. ... CEGUI tightly works together with your graphics library or engine and therefore renders directly to the framebuffer or any other rendertarget you specify., which is very helpful for any application that has restricted performance. This is all not really relevant or even useful once you work on a tool, which doesn't have such performance limits. I think this is one reason why an extensive but "slow" library like qt can be better suited.
On the other hand, I also see a benefit in having the "tool" itself completely decoupled from the thing you are working on (the GUI) in case you have to deal with bugs. CEED actually does have CEGUI in it and does render CEGUI using its very own library. But if all was made with CEGUI, it would be difficult to distinguish bugs occuring in the tool itself from those occuring in the preview we give. On the other hand if there is Qt on one side, and all the UI rendering stuff is entirely seperated, such bugs can easily be distinguished.
In addition to all of this: making a tool with the tool itself seems like a strange task, like building a hammer that helps you with continuing working on itself. However, with qt we have all the qt tools to work on the editor.

Qt and CEGUI are just two totally different libraries, suited for totally different things. CEED could be made entirely with CEGUI but there would be no gain. If I had to make a small editor for a game, which already uses CEGUI, I would definitely go for CEGUI for this editor since I already have that set that up and know to use it (and maybe could reuse the skin?). If I had to make a really extensive editor for a game on the other hand, I would say it depends.
Is it an editor where HUD elements are used as part of your viewer and which features relatively similar and static components --> definitely CEGUI
Is it an editor that is not directly tied to any parts that render a 3D world / previews or is very very complex in terms of dockable windows, has extensive property<->value lists, or any other features Qt is better at --> definitely Qt

I believe Qt was a good decision for this purpose, and this definitely should not suggest to anyone that we were (or are) considering CEGUI to be bad choice for tools. It can be great for tools. You just need to know your requirements and if it fits well ;)

With all that said: Martin could probably give you even better reason, since he made this decision in the first place ( I think ).
CrazyEddie: "I don't like GUIs"

Not too shy to talk
Not too shy to talk
Posts: 33
Joined: Thu Jul 09, 2015 10:20

Re: Why Qt?

Postby iceiceice » Tue Dec 29, 2015 06:13

Another point to consider:

CEGUI is a gui library with *minimal* external dependencies, and that is one of the reasons that people use it.

Qt is much more complicated than CEGUI, to build and to use. For many applications it's still worth it, but for many developers it's a consideration in deciding what to use.

However, most developers who use CEGUI don't also plan to modify the CEED editor code. The Qt stuff, and qt-python bindings, are available on all desktop platforms (save a few rare ones perhaps) in a prebuilt form, so most people have no issue to install and use it.

Besides this, while CEGUI is meant to be used in your blazingly fast C++ games and applications, for CEED its okay to use python even if its a bit slower. So CEED does not have to use Qt via C++ at all, it can use it strictly from python, and the python bindings are arguably a bit simpler than natively using Qt.

So several of the drawbacks of Qt in a C++ application, are not so important where the CEED editor is concerned.

(Note that I had no role whatsoever in decision to engineer CEED this way :mrgreen: )

Return to “Official Unified CEGUI Editor Tool (CEED)”

Who is online

Users browsing this forum: No registered users and 2 guests