Sign in to follow this  

Which GUI toolkit for editor?

This topic is 2592 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi guys,

I have a big question that will influence my work for the next years. I have a little 3D-Engine, writte in C++ and DirectX11. Now I want to write an 3D-editor (kinda like crytek's sandbox, but obviously less advanced) and I just can't decide with GUI toolkit I should use.

These are my candidates and my thoughts about them:

WinForms: I like it. But if I use WinForms I definitely will use C# and now I have the problem how to call my native C++ Engine Code from C#. Since my editor uses almost the entire engine I had to write C++/CLI wrappers around HUGE parts of my C++ engine. Basically I end up having my engine in 2 versions (native and C++/CLI wrapper around everything). Sounds tedious and frustrating:(

WPF: Sounds really cool, but basically the same native-wrapper problem as with WinForms.

QT: From all C++ Toolkits I have seen this looks the best (in terms of window presentation and code). Though it looks like the newest version does not work with DX11?

MFC: Old, ugly, but I could use my native C++ code as it is without any wrappers and performance hits.

As you can see I am kinda lost here. I would love to use WPF or Winforms with C# for my GUI, but the managed/unmanaged boundary problems sounds huge for me. On the other side are the native C++ toolkits, but none of them seems promising to me.

So could you guys tell me your thoughts about this or maybe even share your experiences? What would you recommend me?

Thanks!

Share this post


Link to post
Share on other sites
Most UI toolkits leave some degree of nasty aftertaste in my experience, but if I had to choose a native one, I'd go with Qt. I doubt it would be too hard to hack in DX11 support if you start with the existing DX stuff.

Share this post


Link to post
Share on other sites
One other choice you omitted is wxwidgets, however, I (funnily enough) just started working on my wxwidgets editor again recently, and I absolutely despise it, so I just gave up with it. It's probably just because I'm so used to laying out stuff easily in winforms. So personally I've gone back to doing it in C#. In regards to the CLR wrapper, you probably won't have to wrap as much as you think. Most of the work can be done on the C++ side with the C# side giving input, which often isn't all that much. It'd be things like telling it to select an object with a ray cast (all you actually pass is the mouse coordinates) and such. It really should be quite thin. Just a thought.

Share this post


Link to post
Share on other sites
Quote:
It's probably just because I'm so used to laying out stuff easily in winforms

wxWidgets has addons for Codeblocks (wxSmith and wxFormBuilder )so that you can generate GUIs using WYSIWYG editors, it has the added benefit of being C++ which you want, uses native controls and does its best to conform to any specified GUI guidelines for the OS.

If you want C++ and the kitchen sink then use Qt else I recommend wxWidgets.

Share this post


Link to post
Share on other sites
I tend to agree with knighty33, but I would also challenge you as to why you're writing an engine. Are you trying to make a game, trying to enter the 3rd party engine market, or is it just a hobby and you're really only interesting in tinkering and not making a game?

if it's either of the first two, I'd call you silly and tell you to use something like Unity or UDK.

If it's the third, well, I agree with knighty33, failing that, Qt.

Share this post


Link to post
Share on other sites
Quote:
Original post by XTAL256
...i looked at wxWidgets and Qt. Qt won hands-down. It's more than just a GUI toolkit, it's a full application framework...

Well, actually, so is wxWidgets. At least, it does a lot more than GUI. It has its own string, containers, streams, network stuff, file classes, etc.

Not that that's necessarily a good aspect of wxWidgets. Having used it in the past, I can say its OK, but if I was starting a new project I would use QT.

Share this post


Link to post
Share on other sites
MFC is old and a little cryptic, what with all those macros... but it is still updated by Microsoft, they recently added support for ribbon menus, for example. If you don't need complex compound controls, I would seriously consider this path.

Qt is good and complete, but it is a commercial library, and as such, the use of the free version has a few legal limitations. In addition, you have to use a pre-compiler so your code is not fully stand-alone. I doubt any of this is going to be an issue to anyone here, but this is certainly worth a mention.

Share this post


Link to post
Share on other sites
If you want a free solution, Qt.
I have no development experience with Qt yet, but I read a lot about it (forum posts, documents) and seems it's the best choice for free GUI/app framework. Its framework is so good designed.

If you don't mind to pay a lot of money, C++ builder.
I had a lot of experience with Delphi (same GUI environment with C++ Builder) and it's really good.
But in my opinion, Delphi and C++ builder may be fading out the main stream stage...

So I highly recommend Qt. And I myself will also use Qt if I need to create an editor in C++.


@Bearhugger: Qt now is completely free for any use. They had changed the license for commercial use.

Share this post


Link to post
Share on other sites
I've had over 2 years experience with Qt. I have had much ease of development than I have with any other C++ toolkit. I have used wxWidgets, Gtkmm, Gtk+, etc. They have all their own good qualities and their bad.

I have done DirectX 9, 10, 11 with Qt and while it's not hard to integrate with Qt. It is quite easy. I am awful at DX so my implementation's have been bad but I have gotten them to work.

Qt has excellent documentation that is well documented and down to the point. The gui form designer is by far untouchable by any other gui form editor. Linguist for localisation, Assistant application for documentation.

You have classes for creating COM objects ActiveQt. You have QScopedPointer, QSharedPointer. Which is really easy to use especially have custom delete functors. You rarely have to worry about memleaks as Qt uses parent/children idiom. So when the parent is deleted all of it's children are automatically deleted. Classes are consistent through the api.

Some might complain about MOC (Meta object compiler) but when you use it, you'd learn to appreciate it. You don't have to worry about ugly macros everywhere like MFC, wxWidgets. They might also complain about bloatness. But, if you really look at it. At least you don't have to worry about depending on X many libraries and have so many inconsistence making your code look uglier, or ever have to worry about end users compiling X many libraries just to get your application to work.

Look at all the companies that use Qt and the application's they have made out of Qt. http://qt.nokia.com/qt-in-use .

It will work with your existing code, so you don't have to learn C# and use C++/CLI to make it work. Which will be a lot more work with little benefits. While I have nothing against C#. I just don't think you'd gain really anything, because of the amount of work to get it to work in C#.

If you have any questions about Qt. I'll help you the best I can or you can ask on irc.freenode.net #Qt.

Share this post


Link to post
Share on other sites
Hi,

Althought I'd be the last to advocate the usage of MS-specific technologies (aside for DX which I love), actually using .NET is not really bad.

You don't have to wrap everything that is native C++. You just have to design your UI properly. There are many ways to do that. You generally only need the interface points between the UI and your native code to be managed.

Its really not a problem and using native C++ from managed code is not a problem. It only starts to become a problem when writing in C# but the C# code should be very minimal and without much logic.

Although writing good applications in Winforms or WPF is HARD, and by good I mean production level and with good performance, writing an initial editor is by far the fastest you'd write. Its almost as easy as Java :)

Qt is a great option but I probably wouldn't have chosen it myself even though I developed with it (on Linux but still). The .NET framework is readily available, has great integration with visual studio and is very simple to use.

Also, integrating DX rendering with Winforms is possible but has some limitations. Other than that, its a breeze.

Share this post


Link to post
Share on other sites
.NET isn't bad. It's just bad when trying to interop. Qt would be great for an editor even if you do use DirectX.

@phresnel: Is that open source? Where can I get it, i'd love to look at it.

Share this post


Link to post
Share on other sites
OT:
Quote:
Original post by SeaBourne
@phresnel: Is that open source? Where can I get it, i'd love to look at it.


Yep, open source. It is in the make. You can have a first look at this. Note that release 0.4 features a revised, actually user friendly gui.

You can follow on freshmeat, or deviantArt (more options: here).

I also post IOTDs here :)

Share this post


Link to post
Share on other sites
Quote:
Original post by wqking
If you want a free solution, Qt.
I have no development experience with Qt yet,
...
So I highly recommend Qt. .


Qt may well be the best thing since sliced bread but how can you highly recommend it?

Share this post


Link to post
Share on other sites
Quote:
Original post by theOcelot
Quote:
Original post by BearhuggerIn addition, you have to use a pre-compiler so your code is not fully stand-alone.

Cite please. Google tells me nothing about this:
qt build precompiler.

He's referring to the Qt moc (Meta-Object Compiler). It's a pre-processor that generates the code supporting the QObject type system, as well as Qt Signals and Slots.

If you use Qt Designer (a WYSWYG interface editor), it outputs .ui files. You'll also need to compile them with the uic (User Interface Compiler).

If you use the Qt resource system to archive your program's data files within the executable itself, you'll need to use the rcc (Resource Compiler) to process your files into the executable.

Share this post


Link to post
Share on other sites
Quote:
Original post by Slavik81
Quote:
Original post by theOcelot
Quote:
Original post by BearhuggerIn addition, you have to use a pre-compiler so your code is not fully stand-alone.

Cite please. Google tells me nothing about this:
qt build precompiler.

He's referring to the Qt moc (Meta-Object Compiler). It's a pre-processor that generates the code supporting the QObject type system, as well as Qt Signals and Slots.

If you use Qt Designer (a WYSWYG interface editor), it outputs .ui files. You'll also need to compile them with the uic (User Interface Compiler).

If you use the Qt resource system to archive your program's data files within the executable itself, you'll need to use the rcc (Resource Compiler) to process your files into the executable.



Note that all this is handled automatically by QtCreator.

Share this post


Link to post
Share on other sites
Quote:
Original post by phresnel
Quote:
Original post by Slavik81
Quote:
Original post by theOcelot
Quote:
Original post by BearhuggerIn addition, you have to use a pre-compiler so your code is not fully stand-alone.

Cite please. Google tells me nothing about this:
qt build precompiler.

He's referring to the Qt moc (Meta-Object Compiler). It's a pre-processor that generates the code supporting the QObject type system, as well as Qt Signals and Slots.

If you use Qt Designer (a WYSWYG interface editor), it outputs .ui files. You'll also need to compile them with the uic (User Interface Compiler).

If you use the Qt resource system to archive your program's data files within the executable itself, you'll need to use the rcc (Resource Compiler) to process your files into the executable.



Note that all this is handled automatically by QtCreator.


Actually its handled by qmake, Qts build system. You can also use qmake with VisualStudio or make/nmake files.

cmake has a pretty good qt-support as well and handles all that precompiler stuff.

Share this post


Link to post
Share on other sites
Quote:
Original post by 3Xist3nZ
Quote:
Original post by phresnel
Quote:
Original post by Slavik81
Quote:
Original post by theOcelot
Quote:
Original post by BearhuggerIn addition, you have to use a pre-compiler so your code is not fully stand-alone.

Cite please. Google tells me nothing about this:
qt build precompiler.

He's referring to the Qt moc (Meta-Object Compiler). It's a pre-processor that generates the code supporting the QObject type system, as well as Qt Signals and Slots.

If you use Qt Designer (a WYSWYG interface editor), it outputs .ui files. You'll also need to compile them with the uic (User Interface Compiler).

If you use the Qt resource system to archive your program's data files within the executable itself, you'll need to use the rcc (Resource Compiler) to process your files into the executable.



Note that all this is handled automatically by QtCreator.


Actually its handled by qmake, Qts build system. You can also use qmake with VisualStudio or make/nmake files.

cmake has a pretty good qt-support as well and handles all that precompiler stuff.


No, with QtCreator, you don't have to invoke qmake by hand.
Yes, and leading further, actually rcc, moc and uic handle the stuff.

Sidenote: I am not a begginer in Qt, and have also hacked on qmake to let it spit out Automake compatible filelists (though I haven't requested a merge with mainline yet, dunno if they want it)

Share this post


Link to post
Share on other sites
Quote:
Original post by phresnel
Quote:
Original post by 3Xist3nZ
Actually its handled by qmake, Qts build system. You can also use qmake with VisualStudio or make/nmake files.

cmake has a pretty good qt-support as well and handles all that precompiler stuff.


No, with QtCreator, you don't have to invoke qmake by hand.
Yes, and leading further, actually rcc, moc and uic handle the stuff.

Sidenote: I am not a begginer in Qt, and have also hacked on qmake to let it spit out Automake compatible filelists (though I haven't requested a merge with mainline yet, dunno if they want it)


ok, in this sense you are right, you dont have to invoke qmake by hand.

I never digged very deep into QtCreator, because we dont use it for production code (we still use plain qmake with VS on windows and make on linux). So you are probably a few steps ahead :)

I just played a bit with it and noticed that QtCreator creates the exact same *.pro files i am used to write manually :)

Share this post


Link to post
Share on other sites
Quote:
Original post by 3Xist3nZ
ok, in this sense you are right, you dont have to invoke qmake by hand.


I guess we are both not wrong :)

I just wanted to say, with QtCreator you get the full stack integrated without the user being required to manually run the compilers, just so that no wrong impression is delivered from this thread :D


Quote:
I just played a bit with it and noticed that QtCreator creates the exact same *.pro files i am used to write manually :)


I guess that's because the basic syntax is dead simple :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Slavik81
Quote:
Original post by theOcelot
Quote:
Original post by BearhuggerIn addition, you have to use a pre-compiler so your code is not fully stand-alone.

Cite please. Google tells me nothing about this:
qt build precompiler.

He's referring to the Qt moc (Meta-Object Compiler). It's a pre-processor that generates the code supporting the QObject type system, as well as Qt Signals and Slots.

Ah, thanks for clearing that up.

Share this post


Link to post
Share on other sites
Thanks for all your answers guys:)

I will check out QT the next weeks and if I manage to successfully integrate D3D11 into QT I will stay with it and will be happy that I don't have to write tons of Interop code;)

BTW: SeaBourne, I have sent you a PM.

Share this post


Link to post
Share on other sites

This topic is 2592 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this