Jump to content
  • Advertisement
Sign in to follow this  
MichaelBarth

Another GUI Libraries Thread

This topic is 608 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

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!

Edited by Spirrwell

Share this post


Link to post
Share on other sites
Advertisement

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
I guess I just hope that MFC follows those same standards.

  Eh no. If you had implemented your own rendering backend for it, you'd have noticed. As I said, "game oriented" ones do that.

 

Typical desktop application UI framework does *everything* on its own (windowing, rendering and input handling). Think WPF, Qt, Gtk, JavaFX, Swing, WxWidgets, whatever widgets are exposed through MFC.

 

Stuff like Unreal or Unity have their own UI framework that renders everything through the engine's rendering subsystem. Which is the approach you'd be taking with something like imGUI, Nuklear or libRocket. They dont capture input on their own, nor they render on their own, they're platform agnostic because they have no platform specific code.

 

Since you're not doing a game UI, that approach might not be worth it, and in that case, for C++, there aren't that many multi-platform choices. There is Qt and Gtk, and I'm pretty sure very few people use Gtk for multi platform development.

 

CodeXL, AMD's graphics debugging tool, uses Qt for all platforms. Another multi platform tool that comes to mind is MySQL Workbench, which uses WPF for Windows I believe, and Gtk for Linux. VLC, the popular video player, uses Qt for all platforms.

Edited by TheChubu

Share this post


Link to post
Share on other sites

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.

Edited by Kylotan

Share this post


Link to post
Share on other sites

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? 

Share this post


Link to post
Share on other sites

For game tools, Nuklear looks good (although I would use imGUI to get C++ API instead of C). Intermediate GUI libraries give you an easy way to make a cross-platform tools, although their functionalities have limits so you have to do extra work in GUI programming. Qt is really powerful and it is suitable if you want to cut down development time for a tool in my opinion.

 

If you're using QML, it's not difficult to make new feature. You control all about the GUI with QML and it will call whatever functions you define in C++ to perform your logic.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!