Hello!

I know there's a GUI lib thread on this forum page no less, but my situation and requirements are different and a bit more specific.

Essentially, there's this old tool I have that's written with the Win32 API\MFC and it works. But, being that, it's not cross platform and is not very easy to work with. I want to port it to another API\GUI system to change that.

I plan to use the tool for non-commercial use, but that's not to say somebody else couldn't come along and want to use it for that. Unfortunately, I can't release the source code, not because I don't want to, but simply because I legally can't.

Knowing that, here are the requirements I have for a GUI library:

• Cross-Platform
• Supports embedding both DirectX and OpenGL into 3D viewports (maybe even Vulkan for the future?)
• Something that can supply the same functionality or better than Win32\MFC
• Something that also supports theming (Come on, got to have a dark theme, right?)
• Can be BUILT with Visual Studio (2013), even if it might want you to use another application to work with like Qt Creator (Yes, I know I want this to be cross platform, but I want this tool to be compatible with our current workflow)
• Free
• Doesn't require my code to be open source
• C\C++ (Forgot to mention this, editing it in!)

Bonus:

• Could be used commercially while falling in line with the above requirements
• Can run on the latest service pack of Windows XP
• Has its own input handling system (Keyboard+Mouse) so I don't need an extra thirdparty library just for that.

Now I know one of my requirements is for embedding DirectX to use for viewports, and that's because the code for that is already there in the application. I'd rather start with something that already works than have to worry about re-working the rendering at the start of the porting process.

Also one of my bonus points is being able to run on the latest service pack of Windows XP, and that's because ideally I'd like to port with the same functionality and not lose anything. If I have to settle for Vista+, that's okay, but I figured I'd add that in there.

If somebody knows of a library that will work for what I need, please let me know! I know I'm asking for quite a lot. I appreciate any input!

Have you looked at wxWidgets?

I have heard about that before, but doesn't that adapt its theming to that of the OS and that's why Code::Blocks doesn't really have theming which so annoys me.

Supports embedding both DirectX and OpenGL into 3D viewports (maybe even Vulkan for the future?)

Often game oriented UI libs will not render themselves to anything. They'll provide a list of primitives (commands if you will) that you'll need to render on your own. Stuff like imGUI, Nuklear or libRocket do this. This is ideal since you dont have a black box messing up your rendering state.

That makes sense. I guess I just hope that MFC follows those same standards. If not, porting this is just going to be so FUN. I'll take a look at these.

Oh and I can't believe I completely forgot to mention the language I'm using, though I guess it might be obvious. C\C++.

Just to follow on what was said in the last post: it's important to be clear on what sort of "GUI library" is in question - usually when we're asking for GUI libraries on this forum, we're talking about how to render UI elements inside a game's existing rendering system, e.g. for HUDs, in-game menus, etc. These systems are usually completely platform-independent as they rely on your game code to perform the rendering and handle the input on its behalf. These are the imGUI, Nuklear, libRocket, CEGUI type of toolkit.

But for tooling questions, that's usually asking for a GUI framework which permits a DirectX/OpenGL window to be embedded within it, which our game renders to. They may pass on input to the game window, but otherwise won't interact with it, apart from providing space in the layout for it. Each platform tends to provide its own library for this (or many libraries, in the case of Windows and MFC, WPF, Windows Forms, etc.) and also available are cross-platform abstraction layers that sit on top of these, such as wxWidgets, TK, QT, etc.

These 2 types of toolkit are almost entirely separate, although there are some ways to twist one into the other - e.g. some atrocities where people would lock DirectX surfaces to render MFC controls onto them - but usually the very different constraints and requirements mean they need to be viewed as separate categories.

I see. I wasn't aware that there was a distinction between the two. Though that's confusing since a GUI framework would also be a series of libraries.

I suppose to explain better, the application I'm interested in porting is a level editor of sorts. It's not directly tied into the game engine it works with, heck it doesn't even have real-time rendering of lights and whatnot. In terms of UI, it's a lot like 3DS Max with 4 viewports that are inter-changeable with typically one 3D view. I feel like Qt would work really well with this, I just wasn't sure about its licensing, though it seemed like I could use it without having to release the source code so long as it's dynamically linked to. However I would like to do this the "right way" so to speak. I don't want to start down one path and find out later when I want to implement some sort of feature, that I need to work against some weird layer of abstraction that something like Qt might have.

Obviously if I use one of these plain GUI libraries it seems like I'll have a lot more work to do, but I won't have to work against the library since I'm defining its implementation. nuklear seemed quite interesting. It's C, so it's going to kill my brain a bit, but one of the people I work with loves plain C. Though even he thinks I should just go with Qt.

Hm... I'm really just not sure what to go for. For long term development, which way is the better way to go?