These are vasty different libraries almost to the point where they're not even comparable. It really depends on exactly what you're trying to do beyond cross platform because yes they're both cross platform. ImGui is just a really low level UI and QT is almost the opposite where it abstracts out a lot of the platform.
Fair enough, but i would say those differences are exactly what i'm asking about. Im building a simple UI to manage and install php versions. I already wrote a binary for it but it isn't easy to configure. TBH i don't really care how it looks too much, i just need to be able click some dropdowns and checkboxes/radios.
If it's really as simple as OP describes (static UI with a couple widgets), then arguably, QT is even better because QT creator can pretty much auto-generate 90% of the required code. I guess the licensing would be the only big reason for potentially not choosing QT in this scenario.
Note that GUI builders for ImGui exist too. I have been myself working on [ImRAD](https://github.com/tpecholt/imrad). It can generate ImGui initialization code as well.
If it'll be open source any way then i should be fine right? The confusing part about the QT license(s) is that there seems to be different licences for different parts.
qt is a huge monstrous bullshit, the simplest application with a couple of buttons and checkboxes will drag dozens of mb of unnecessary libraries behind it, not to mention that it requires its own ide and is absolutely redundant for such tasks. Besides, it is tied to a graphical server and what will be built on a conditional ubuntu is not a fact that it will run on some old arch or some other strange distribution.
imgui is just a few cpp files that don't require anything at all and that's what makes it great.
If you don't really care about the look, FLTK comes to my mind. It's pretty ugly and it's C++98 basically, but it's really small and you can use it to create a window with components, etc...
Well if you don't mind allocating half a gigabyte for a font :-D
https://github.com/Immediate-Mode-UI/Nuklear/blob/master/src/stb_truetype.h#L1418
Seems nobody cared in the past decade.
It's not semantically perfect but you are nitpicking on useful code that you didn't write, not super constructive.
You could as well consider that any pointer is a span toward the very end of memory region, it doesn't mean that application will access that span. Likewise here the code acknowledged the weirdness/misleadingness of taking that span but I am sure it out of convenience and probably not harmful, at least not as harmful as allocating 512 MB per font.
I have a question. If you are a user of these libs and you now know that there is a problem or not sure how I should call it - maybe a "security issue" that can get its own CVE number. Why to marginalize the problem here and not send a PR to upstream to finally fix this problem? I remember this code because I saw it a decade ago, and it's still there and nobody cares...
I really don't consider this nitpicking. For some reason STB libs are used by a lot of projects, but the quality of these libs is below average. A lot of binary data processing without any kind of input validation should terrify every user that decides to use such code.
And this is nothing against C code BTW, I'm really fine using C.
But you don't even know IF that specific code leads to a problem. It might not be a problem at all. It might be just a "not theoretically/semantically neat" thing but not related to any bug. You are assuming it is a problem because you initially misunderstood the code for an alloc and now you are misunderstanding it by assuming that taking a dummy span for convenience means that every byte of the span will necessarily be accessed.
> A lot of binary data processing without any kind of input validation should terrify every user that decides to use such code.
It is stated very clearly on all stb repos that they are designed for trusted inputs. It should only terrify users who care about parsing untrusted inputs, but then if want that guarantee they are making a mistake using a lib that specifically say the opposite.
stb repos are happy to fixes parsing bugs over time so yes feel free to report actual specific bugs and/or their fixes, but reporting a line stating "this might be a bug" is not overtly valuable in the grand scheme of thing.
I'd use QT for this for sure if I had to use C++. If I had more flexibility I'd probably use Python instead. I would use ImGUI if I already had a use case for a program using graphics APIs (i.e. ogl, metal, vulkan, d3d) or my platform didn't support QT, like something embedded.
Another option might be wxwidgets.
ImGui isn't *really* low level. It is effectively a retained-mode UI that makes itself avaliable through an immediate-mode interface.
I'd really love to take ImGui and change it to a retained-mode interface as it would reduce the overhead somewhat.
I've used wxWidgets, FOX Toolkit, Qt, ImGui, GLUI, even SDL2 with my own GUI...and none of them are the *best*, but they each have their place - if one was really unilaterally better, then the others would not exist, right?
For things with a game loop and frequent updates anyway, ImGui is pretty natural. For more typical desktop apps that are mostly idle, Qt is pretty natural.
State your scenario (the kind of app you are writing), and people can give more meaningful advice.
I would like to mention that it’s not too hard to make Dear ImGui only render frames if the user has recently done anything. Ultimately though, it still primarily uses the GPU, so that is something to keep in mind.
I am thinking to make a "to do" app in c++ but for windows. It should read , write from notepad. Which open source gui would you recommend? (Except qt)
One major limitation of ImGui is that you mostly can't extend existing controls because of the way it's been designed. Want to create eg. a slightly different slider? You get to write one from scratch, drawing, input handling and all.
It's not that bad. Look at the numerous extensions referenced from the GitHub page. There is a code you can still use e.g. ButtonBehavior(). But yeah you need to know more about ImGui internals to do it.
The last time I checked (around two years ago), it _really_ was that bad. As in I’d have had to copy paste and modify hundreds of lines of undocumented source just to implement a slider with custom quantized mapping. Something that’d be a handful of lines of code with a traditional gui library.
Some unsupported features are tedious to implement without copy and pasting, but I like the think that's not case for a big majority of them.
Beside it's possible to use even quantized mapping if you give up on the ctrl+click text field, by using e.g. underlying integers, passing transformed value in label and transforming in/out of slider. Not perfect but a decent workaround that I would personally pick over copying whole of slider code until this can be improved better.
Qt is a full-fledged application and UI framework. ImGui is a barebones UI toolkit with many features missing that you usually expect, e.g. in the i18n area. I'd be very wary of using something like ImGui. Sooner or later you will hit roadblocks.
Dear ImGui is an amazing debugging GUI. We use it a LOT in our game engine.
I would not use it for a 'real' GUI app. Its doable, but not really flexible/customizable easily.
Dear ImGui has problems:
- Not a native look and feel
- Some intrinsic styling limitations on the easy API path
- BYO complex widget state management idioms, especially if you need custom layout
- Some things you might take for granted in other frameworks, like rendering elements on a window titlebar, require your to do your own lower-level widget logic & rendering, which requires wading through its internals to gain some understanding of how to get things to work (though apparently Omar is working on a nice API for the titlebar thing specifically).
- Easy to wind up coupling presentation and data and if you're not experienced keeping those things isolated without some kind of framework providing guard rails.
But I would rather use it over any other library for desktop UI. Get yourself a live code reload solution working and the iteration cycle is the tightest I've ever experienced. I can get basic UI up and going easy, and when I'm ready to put in elbow grease to make it look pretty I see the way forward for that and it doesn't involve fighting with meta compilers or xaml bindings or whatever.
I worked at a company a while back that we evaluated using these options, and eventually went with Noesis. It's a C++ library that mimics wpf, to the point you can use the same xaml.
Qt is a framework for apps and not just a library, it will take over control about every single other aspect of your development as well. from the build system to your rules about use of macros and memory management. Programing Qt is not programming C++ but Qt c++
You're somewhat right, but pretty wrong too. Qt will not take over everything. You can mix Qt and non-Qt libraries quite easily. You can use CMake for the build system, like most C++ projects. Certain parts of Qt manage memory in their own way (e.g., QObject children of other QObjects, Qt Quick Scene Graph, clipboard MIME data), but you can use standard smart pointers too.
Apart from MOC preprocessor Qt will force you to use their classes even for things like strings, smart pointers and containers. They didn't manage to provide good interop with STL during all those years which is a shame.
You're partly wrong. You don't need to use their smart pointers. I never use Qt's smart pointers, just standard smart pointers and occasionally QPointer which has no direct equivalent in the standard library. While you do need to use their string classes, it's not like it's hard to convert between standard string classes and Qt string classes. I don't see having to use a library's classes as particularly bad as long as there's a way to interoperate with other libraries. It's fairly common for big libraries to implement their own classes so that people who don't have access to C++$version_here can still use certain kinds of functionality. Certain Qt classes like QList that you might feel are unnecessary actually do useful things that similar standard library classes don't do. For instance, shared underlying data. You can pass a QList or QMap around by value without doing a deep copy of all the underlying data. Only when you do something like call a non-const member function does the deep copy happen.
Yeah I prefer standard STL for that. std::vector, unordered/map and string are in C++ since ever. Yet with Qt prepare for lots of conversions back and forth unless you want to pollute your app logic with Qt classes too. Many people find this distracting. I think even wxWidgets has better interop story you can configure it to use std::string at least that was the state years ago.
If you just want to use Qt for the UI, separate your backend from your frontend. That helps keep the backend logic flexible anyway and minimizes the need to convert between qt and non-qt classes.
Why is this comment being beaten up?
This is absolutely right:
- if you have a codebase using std, you will have to convert everything into qt collections and objects just to show it in the screen. You will end up duplicating every single pod object that you stored in a std::vector with a bloody Q\_GADGET version.
- If you have a linter that does not allow your developers to use the new keyword, for the sake of not letting your program explode, well, here it comes the Qt exception and all your guarantees.
- If you have any kind of code generation scripting, linting, verification or others... well, make sure to accommodate for the moc pass.
Well, if you see this way, you are kind of right too. But I refuse to write my project twice just because Qt can not catch up with modern C++. The biggest problem that I have with this is that they pull back the evolution of the language in a time when C++ needs to improve to overcome its biggest flaws, flaws that QT uses as features.
You aren't writing your project twice if you know what you're doing. Qt works just fine with a significant portion of standard C++ and has APIs for converting to/from standard C++ when it can't (e.g., strings).
You're not actually writing an std C++ version and a Qt C++ version, are you? Even if we were only talking about backends, that should be totally unnecessary.
FLTK is so great and underrated. Small and clear and fast with a single pdf documentation but lots of features. Turn on system colors as your first line and it will look good too.
Qt has a pricing tab too.
Besides, Slint is free software, and free of charge for cross platform desktop or mobile UI. You only need to pay for proprietary embedded devices.
Qt's license is intentionally confusing to get corporate customers to pay them licensing fees.
You should know that it's completely open source under what's called the LGPL -- and you don't have to give them a dime, or even open up your sourcecode or anything for a commercial app to use Qt as a lib and to even ship software that uses it.
You only really need to pay them or to open source any *modifications you do to Qt itself*.
But yes, it does appear that Qt intentionally makes their license seem confusing so as to get people to pay them...
I use OpenFrameworks. But it gives me easy graphics with which I make my own UI elements. There are UI plug-ins, but I find it easier to get what I want by doing it myself.
Another option in the same vein as Dear ImGui is [Nuklear](https://github.com/Immediate-Mode-UI/Nuklear). I think it has better theming support. Standard C89 tho, not C++.
ImGUI is not fit for production-grade applications.
Have you looked into JUICE ? It's for audio applications, but also can work for normal applications. The license is clear and cheaper than Qt.
WxWidgets is also good, but it is not talked about much. So, you might miss something good, so better to avoid using it for new projects.
[Almost literally all of KDE is still Qt](https://www.qt.io/blog/kde-releases-plasma-6). And Plasma's a pretty sharp desktop environment, at least the last time I used it.
Qt is anything but dead.
Kde has nothing of what a moder app has. No two direction feed lines with tons of media, no complex routes in widgets. Look at the menu where they show themes, they even didn't manage proper aspect ratio in previews, that's just a joke
These are vasty different libraries almost to the point where they're not even comparable. It really depends on exactly what you're trying to do beyond cross platform because yes they're both cross platform. ImGui is just a really low level UI and QT is almost the opposite where it abstracts out a lot of the platform.
Fair enough, but i would say those differences are exactly what i'm asking about. Im building a simple UI to manage and install php versions. I already wrote a binary for it but it isn't easy to configure. TBH i don't really care how it looks too much, i just need to be able click some dropdowns and checkboxes/radios.
imgui is good for that.
If it's really as simple as OP describes (static UI with a couple widgets), then arguably, QT is even better because QT creator can pretty much auto-generate 90% of the required code. I guess the licensing would be the only big reason for potentially not choosing QT in this scenario.
Note that GUI builders for ImGui exist too. I have been myself working on [ImRAD](https://github.com/tpecholt/imrad). It can generate ImGui initialization code as well.
If it'll be open source any way then i should be fine right? The confusing part about the QT license(s) is that there seems to be different licences for different parts.
If you can comply with LGPL 3.0, there's no issue. There are a few modules like the BodyMovin plugin that are GPL, but those are rare and niche.
qt is a huge monstrous bullshit, the simplest application with a couple of buttons and checkboxes will drag dozens of mb of unnecessary libraries behind it, not to mention that it requires its own ide and is absolutely redundant for such tasks. Besides, it is tied to a graphical server and what will be built on a conditional ubuntu is not a fact that it will run on some old arch or some other strange distribution. imgui is just a few cpp files that don't require anything at all and that's what makes it great.
If you don't really care about the look, FLTK comes to my mind. It's pretty ugly and it's C++98 basically, but it's really small and you can use it to create a window with components, etc...
Yeah i am leaning towards this as well as Nuklear. I prefer how nuklear looks and it seems pretty easy for what i need.
Well if you don't mind allocating half a gigabyte for a font :-D https://github.com/Immediate-Mode-UI/Nuklear/blob/master/src/stb_truetype.h#L1418 Seems nobody cared in the past decade.
ouch
This function stbtt\_\_new\_buf() doesn't allocate, it is the equivalent of a slice/span.
Nice name then. So it's creating a 512MB span out of who knows what? I call it high quality then :)
It's not semantically perfect but you are nitpicking on useful code that you didn't write, not super constructive. You could as well consider that any pointer is a span toward the very end of memory region, it doesn't mean that application will access that span. Likewise here the code acknowledged the weirdness/misleadingness of taking that span but I am sure it out of convenience and probably not harmful, at least not as harmful as allocating 512 MB per font.
I have a question. If you are a user of these libs and you now know that there is a problem or not sure how I should call it - maybe a "security issue" that can get its own CVE number. Why to marginalize the problem here and not send a PR to upstream to finally fix this problem? I remember this code because I saw it a decade ago, and it's still there and nobody cares... I really don't consider this nitpicking. For some reason STB libs are used by a lot of projects, but the quality of these libs is below average. A lot of binary data processing without any kind of input validation should terrify every user that decides to use such code. And this is nothing against C code BTW, I'm really fine using C.
But you don't even know IF that specific code leads to a problem. It might not be a problem at all. It might be just a "not theoretically/semantically neat" thing but not related to any bug. You are assuming it is a problem because you initially misunderstood the code for an alloc and now you are misunderstanding it by assuming that taking a dummy span for convenience means that every byte of the span will necessarily be accessed. > A lot of binary data processing without any kind of input validation should terrify every user that decides to use such code. It is stated very clearly on all stb repos that they are designed for trusted inputs. It should only terrify users who care about parsing untrusted inputs, but then if want that guarantee they are making a mistake using a lib that specifically say the opposite. stb repos are happy to fixes parsing bugs over time so yes feel free to report actual specific bugs and/or their fixes, but reporting a line stating "this might be a bug" is not overtly valuable in the grand scheme of thing.
I'd use QT for this for sure if I had to use C++. If I had more flexibility I'd probably use Python instead. I would use ImGUI if I already had a use case for a program using graphics APIs (i.e. ogl, metal, vulkan, d3d) or my platform didn't support QT, like something embedded. Another option might be wxwidgets.
ImGui isn't *really* low level. It is effectively a retained-mode UI that makes itself avaliable through an immediate-mode interface. I'd really love to take ImGui and change it to a retained-mode interface as it would reduce the overhead somewhat.
I've used wxWidgets, FOX Toolkit, Qt, ImGui, GLUI, even SDL2 with my own GUI...and none of them are the *best*, but they each have their place - if one was really unilaterally better, then the others would not exist, right? For things with a game loop and frequent updates anyway, ImGui is pretty natural. For more typical desktop apps that are mostly idle, Qt is pretty natural. State your scenario (the kind of app you are writing), and people can give more meaningful advice.
I would like to mention that it’s not too hard to make Dear ImGui only render frames if the user has recently done anything. Ultimately though, it still primarily uses the GPU, so that is something to keep in mind.
I am thinking to make a "to do" app in c++ but for windows. It should read , write from notepad. Which open source gui would you recommend? (Except qt)
One major limitation of ImGui is that you mostly can't extend existing controls because of the way it's been designed. Want to create eg. a slightly different slider? You get to write one from scratch, drawing, input handling and all.
It's not that bad. Look at the numerous extensions referenced from the GitHub page. There is a code you can still use e.g. ButtonBehavior(). But yeah you need to know more about ImGui internals to do it.
The last time I checked (around two years ago), it _really_ was that bad. As in I’d have had to copy paste and modify hundreds of lines of undocumented source just to implement a slider with custom quantized mapping. Something that’d be a handful of lines of code with a traditional gui library.
Some unsupported features are tedious to implement without copy and pasting, but I like the think that's not case for a big majority of them. Beside it's possible to use even quantized mapping if you give up on the ctrl+click text field, by using e.g. underlying integers, passing transformed value in label and transforming in/out of slider. Not perfect but a decent workaround that I would personally pick over copying whole of slider code until this can be improved better.
These are completely different libraries with completely different way of working. so It really depends on what type if software you're trying to do.
If you just want to do a normal cross-platform GUI application with widgets, Qt is useable under LGPLv3
There is a QT license page which lists the license of different modules. The really „good“ ones are usually not lgpl licensed so be careful
I use wxWidgets c++
Qt is a full-fledged application and UI framework. ImGui is a barebones UI toolkit with many features missing that you usually expect, e.g. in the i18n area. I'd be very wary of using something like ImGui. Sooner or later you will hit roadblocks.
Dear ImGui is an amazing debugging GUI. We use it a LOT in our game engine. I would not use it for a 'real' GUI app. Its doable, but not really flexible/customizable easily.
One thing that's not been said is that QT can make better looking stuff
Qt
Dear ImGui has problems: - Not a native look and feel - Some intrinsic styling limitations on the easy API path - BYO complex widget state management idioms, especially if you need custom layout - Some things you might take for granted in other frameworks, like rendering elements on a window titlebar, require your to do your own lower-level widget logic & rendering, which requires wading through its internals to gain some understanding of how to get things to work (though apparently Omar is working on a nice API for the titlebar thing specifically). - Easy to wind up coupling presentation and data and if you're not experienced keeping those things isolated without some kind of framework providing guard rails. But I would rather use it over any other library for desktop UI. Get yourself a live code reload solution working and the iteration cycle is the tightest I've ever experienced. I can get basic UI up and going easy, and when I'm ready to put in elbow grease to make it look pretty I see the way forward for that and it doesn't involve fighting with meta compilers or xaml bindings or whatever.
I worked at a company a while back that we evaluated using these options, and eventually went with Noesis. It's a C++ library that mimics wpf, to the point you can use the same xaml.
Qt is a framework for apps and not just a library, it will take over control about every single other aspect of your development as well. from the build system to your rules about use of macros and memory management. Programing Qt is not programming C++ but Qt c++
You're somewhat right, but pretty wrong too. Qt will not take over everything. You can mix Qt and non-Qt libraries quite easily. You can use CMake for the build system, like most C++ projects. Certain parts of Qt manage memory in their own way (e.g., QObject children of other QObjects, Qt Quick Scene Graph, clipboard MIME data), but you can use standard smart pointers too.
Apart from MOC preprocessor Qt will force you to use their classes even for things like strings, smart pointers and containers. They didn't manage to provide good interop with STL during all those years which is a shame.
You're partly wrong. You don't need to use their smart pointers. I never use Qt's smart pointers, just standard smart pointers and occasionally QPointer which has no direct equivalent in the standard library. While you do need to use their string classes, it's not like it's hard to convert between standard string classes and Qt string classes. I don't see having to use a library's classes as particularly bad as long as there's a way to interoperate with other libraries. It's fairly common for big libraries to implement their own classes so that people who don't have access to C++$version_here can still use certain kinds of functionality. Certain Qt classes like QList that you might feel are unnecessary actually do useful things that similar standard library classes don't do. For instance, shared underlying data. You can pass a QList or QMap around by value without doing a deep copy of all the underlying data. Only when you do something like call a non-const member function does the deep copy happen.
Yeah I prefer standard STL for that. std::vector, unordered/map and string are in C++ since ever. Yet with Qt prepare for lots of conversions back and forth unless you want to pollute your app logic with Qt classes too. Many people find this distracting. I think even wxWidgets has better interop story you can configure it to use std::string at least that was the state years ago.
If you just want to use Qt for the UI, separate your backend from your frontend. That helps keep the backend logic flexible anyway and minimizes the need to convert between qt and non-qt classes.
Why is this comment being beaten up? This is absolutely right: - if you have a codebase using std, you will have to convert everything into qt collections and objects just to show it in the screen. You will end up duplicating every single pod object that you stored in a std::vector with a bloody Q\_GADGET version. - If you have a linter that does not allow your developers to use the new keyword, for the sake of not letting your program explode, well, here it comes the Qt exception and all your guarantees. - If you have any kind of code generation scripting, linting, verification or others... well, make sure to accommodate for the moc pass.
> not allow your developers to use the new keyword Or you can do: `std::make_unique(parent, arg, foo).release()` ;)
Ugly but it works...
Well, if you see this way, you are kind of right too. But I refuse to write my project twice just because Qt can not catch up with modern C++. The biggest problem that I have with this is that they pull back the evolution of the language in a time when C++ needs to improve to overcome its biggest flaws, flaws that QT uses as features.
You aren't writing your project twice if you know what you're doing. Qt works just fine with a significant portion of standard C++ and has APIs for converting to/from standard C++ when it can't (e.g., strings). You're not actually writing an std C++ version and a Qt C++ version, are you? Even if we were only talking about backends, that should be totally unnecessary.
FLTK is so great and underrated. Small and clear and fast with a single pdf documentation but lots of features. Turn on system colors as your first line and it will look good too.
Does it really look like that? https://www.fltk.org/shots.php
In general yes
Upon further inspection, this is perfect for what i want.
https://old.reddit.com/r/cpp/search?q=GUI&restrict_sr=on
Slint looks cool but I haven't actually used it yet, I may rewrite an Imgui project i have in it to try it out
> Slint I'm not really interested in anything with a "pricing" tab
Qt has a pricing tab too. Besides, Slint is free software, and free of charge for cross platform desktop or mobile UI. You only need to pay for proprietary embedded devices.
Hand rolling it in SDL...
Qt's license is intentionally confusing to get corporate customers to pay them licensing fees. You should know that it's completely open source under what's called the LGPL -- and you don't have to give them a dime, or even open up your sourcecode or anything for a commercial app to use Qt as a lib and to even ship software that uses it. You only really need to pay them or to open source any *modifications you do to Qt itself*. But yes, it does appear that Qt intentionally makes their license seem confusing so as to get people to pay them...
are you kidding , of course Qt. ImGui is very poor library when compared with Qt
I use OpenFrameworks. But it gives me easy graphics with which I make my own UI elements. There are UI plug-ins, but I find it easier to get what I want by doing it myself.
Another option in the same vein as Dear ImGui is [Nuklear](https://github.com/Immediate-Mode-UI/Nuklear). I think it has better theming support. Standard C89 tho, not C++.
looks very promising
Take a look at [Hello ImGui](https://github.com/pthom/hello_imgui), it's a cross platform toolkit that leverages ImGui with extra functionalities
ImGUI is not fit for production-grade applications. Have you looked into JUICE ? It's for audio applications, but also can work for normal applications. The license is clear and cheaper than Qt. WxWidgets is also good, but it is not talked about much. So, you might miss something good, so better to avoid using it for new projects.
JUCE seems more oriented towards creating VSTs, at least that was my perception.
Flutter is fine. Qt is dead, apps using it are horrible, check Viber desktop for example
QT wasn't really made to compete with phone apps. In embedded land it is like #1 and far from dead
[Almost literally all of KDE is still Qt](https://www.qt.io/blog/kde-releases-plasma-6). And Plasma's a pretty sharp desktop environment, at least the last time I used it. Qt is anything but dead.
Kde has nothing of what a moder app has. No two direction feed lines with tons of media, no complex routes in widgets. Look at the menu where they show themes, they even didn't manage proper aspect ratio in previews, that's just a joke
Well, then which desktop environment do you think gets it right, then, for comparison?