GUI framework for game/engine tools?

[Singulus]

I've just skimmed all threads here containing "mfc", but I didn't find what I'm looking for. So, here is what it is:
- As a side project (with a mid-range plan to become the base of my mISV), I plan to begin to develop a level/scene/ai/physics editor supplementing a game engine. The similar applications are Radiant (Quake/Doom engines - Id Software), UnrealEd (Unreal Engine - Epic Games), Sandbox - CryEngine, Crytek), etc. The main features of this kind of windows application are:
- main view window, rendering a 3d scene with the same code that is the renderer part of the game engine
- one or more tree views on the side, for example representing the hierarchical structure of the scene graph, physics entities, etc.
- numerous dialog boxes OR panels in the fore-mentioned side panel

Nothing fancy, just a useful functionality, in the beginning only for us, the developers of the engine, in the long-term the application might become the official level editor of the game engine. There is no need for some sort of "brand" or "recognizable" GUI (like Adobe apps for example). Just to get the work done easily and without quirks.

One of my core concerns - interoperability of the unmanaged C++ code in the engine DLLs and the front end application (the editor). The main candidates are:

- MFC: my personal favorite. I'm relatively proficient with it, nothing spectacular, but I have fairly good knowledge of its overall structure (MVC, messages, etc.).
Recently I've read a thread here ("Microsoft is pushing C++"), where I've read many optimistic things about the near future of MFC as a GUI framework for Windows with Visual Studio. Now the cons: I have a small doubts that the speed of GUI development will be far slower compared for example with .NET framework, but this is not tested, only an assumption. Correct me if I'm wrong.

- WTL: Previously abandoned by Microsoft GUI framework, now somewhat resurrected, I've read numerous post around the net that it is used commercially in many game development studios.
Pros: lightweight, native C++, Microsoft based (I'm not sure whether this is a pro or cons?!?)
Cons: not officially supported by Microsoft, insufficient documentation, lack of numerous tutorials and samples on the internet.

- .NET framework:
Pros: The newest GUI technology for Microsoft platforms, easy to implement fairly featurefull GUI applications
Cons: Managed code, what bugs me most is how painless will be the integration of the native C++ code (the engine) within a .NET GUI application.

- Borland C++ VCL (part of Borland Developer Studio/C++ Builder):
Pros: As a predecesor of .NET framework, I have ~3 months working experience with Borland C++ Builder doing GUI programming and I have to say that it is a breeze to develop that kind of stuff (especially the lack of experience with VCL prior that).
Cons: What bugs me here is again integration of game engine DLLs, developed in Visual Studio within a VCL app.
Another concern is that apparently Borland are abandoning the C++ Builder.

- Some other GUI frameworks/toolkits: wxWidgets, GTK, etc. I don't know anything about these, only the names and their platform independence. What concerns me is the stability of the libraries and again the integration and some issues for using rendering module within them.

- Doing the GUI stuff as a part of GUI elements directly with the game engine. This is an extreme, but not impossible at all.
Pros: the development of various GUI elements renderable with the game engine will make a base for GUI for the game itself, which is a very good thing.
Cons: the development of the needed GUI elements will take a lots of time, I prefer instead to work on core engine functionality.

Thanks, all useful replies are appreciated.

[zoombapup]

wxWidgets should be relatively stable, considering its been used in tons of projects.

My suggestion, would be to go with .net and C# for the interface and use your core engine code with some kind of wrapper. C# is almost purpose built for these kind of things.

Use the best tech for what its good at. C# is great for tools/app interfaces.

[Nikster]

I second .net/c# now I use it on a daily basis, and interopping with your unmanaged c++ is a simple case of getting the code in a dll and essentially doing
a prototype for the function managed side, it really is easy, and as you've already spent so much time with MFC you'll see straight away the benefits in .net, message sinking and the like, gone... :)

[Bad Sector]

I build my interfaces in Lazarus (http://lazarus.freepascal.org/). It's like Delphi (and FCL/LCL is very similar to VCL), but opensource (so won't get abandoned - at least not anytime in the near future) and multiplatform (Windows, Linux, MacOS X and some others probably). Sure, the hard part is interfacing your engine with the Lazarus program (just like the C# vs C++ or whatever). Personally i've solved this by making a special "editor module" in the engine that does the actual editing and this module exposes some C functions which then are imported from the Lazarus program.

Note that if your engine is C-based, you have more luck, since Lazarus has a H-to-Unit converter. Also interfacing C++ shouldn't be *very* hard (although never tried it myself). They interfaced Qt, which is a very C++ heavy thing.

[Huge]

I have done my fair share with wxWindows - and it is pretty easy once you get going. I think any system is going to work with an engine because you can always get the HWND and go from there.
Once piece of advise for editor design: use the view-model-controller design.
Here you separate out a model with "data" - no viewing, no ui. So it is a bunch of "data" classes. Ideally you can write a header file for this without reference to "windows.h" or "engine.h" (engine.h would include your model.h).
This, in theory, this would let you replace you editor and still have your engine and model work correctly. You still have to do a bit of blurring - nothing is ideal. For example, you could have a "selected" attribute on your model objects - this would not make much sense in your game, but by allowing your engine draw "selected" object differently, you still get good separation.

Another good pattern is the observer pattern. Here you split your gui into bits that do not talk to each other directly. For example, say in you wysiwyg editor window, you select an object. The VMC works like this:
The window asks your engine "give me object ID at location x,y". It then says "Model, set object ID to selected". The model does this and then broadcasts "object selection changed". The engine hears this message and updates the display - and also your gui-tree-view hears this and highlights the object name in the tree. This way you can add gui components in a very scalable way. You may think of other ways to select objects (key bindings for example) and all they have to do is set values on the model and listen for broadcasts and they will work perfectly with your other objects.

[barrygamer]

FLTK? http://www.fltk.org/
I think its the most lightweight of the c++ cross-platform UI libs (i.e. Qt, wxWidgets etc). I used it for a non-game project many moons ago.