CEGUI (Crazy Eddie's GUI) Forums

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

Why not using CEGUI for that?

Doesn't Qt use CEGUI for Qt Creator?

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 ).

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 )