GUI frameworks are big because they do a lot. These minimalist things usually only work until you reach the limits of what they can do and then you have to rewrite in something like Qt anyway, or sacrifice what your users want in a GUI for your own code aesthetics.
It doesn’t even take much to reach the limits of tiny GUI toolkits. Very common things like native file/directory selection dialog (preferably with format/suffix filtering) rule out a whole slew of “tiny GUI toolkits”. You can use a puny GUI and find out halfway that widgets you need just aren’t there or require tremendous customization efforts, or you can use Qt and have the widest selection while conforming to accessibility standards and at the same time not look like crap. The choice is obvious to me (after hard-earned lessons).
Is Qt so bad by modern standards? Admittedly I don't have hard numbers, but I believe it's far less bloaty than Electron, even when using its web-like features (QML and JavaScript).
Let's not forget just how low the bar has been set by Electron. Microsoft Teams manages to use 600MB of RAM.
The opposite is true, people move away from Qt because even if it's more complete it's also heavy. Of course, it has internationalization and accessibility. The smaller API, higher performance, faster development of Dear Imgui is more important for me.
Some reported that moving from Qt to Dear Imgui resulted in a codebase three-time smaller.
It’s be helpful to have some concrete examples of where one might run into limits with the minimalist frameworks and why a larger framework is required to overcome those limits.
file open/save dialogs, i18n, drag and drop, image formats, web views, any sort of accessibility, themability that actually fits into native platforms, sometimes the ability to open new windows, many common controls that we just take for granted now that you have to implement yourself, sometimes limited amount of events you can reasonably handle based on the design of the api (IM gui's for instance).
I wouldn't say never use an minimalist framework. It can be handy for embedded debugging tools or for toy projects. But I wouldn't use one of these things for an application that I thought might have a few thousand users and some sort of life span.
Thanks for the list. I'll keep these in mind for my next GUI project. I've used Qt a few times for hobby projects, but was thinking about trying something else for my next GUI project.
Comments
GUI frameworks are big because they do a lot. These minimalist things usually only work until you reach the limits of what they can do and then you have to rewrite in something like Qt anyway, or sacrifice what your users want in a GUI for your own code aesthetics.
It doesn’t even take much to reach the limits of tiny GUI toolkits. Very common things like native file/directory selection dialog (preferably with format/suffix filtering) rule out a whole slew of “tiny GUI toolkits”. You can use a puny GUI and find out halfway that widgets you need just aren’t there or require tremendous customization efforts, or you can use Qt and have the widest selection while conforming to accessibility standards and at the same time not look like crap. The choice is obvious to me (after hard-earned lessons).
I've found nativefiledialog to be quite good for that use case
Well said. And remember, it's not just what your users want, but what some of them need, e.g. accessibility. Enough said about that. :)
Is Qt so bad by modern standards? Admittedly I don't have hard numbers, but I believe it's far less bloaty than Electron, even when using its web-like features (QML and JavaScript).
Let's not forget just how low the bar has been set by Electron. Microsoft Teams manages to use 600MB of RAM.
The opposite is true, people move away from Qt because even if it's more complete it's also heavy. Of course, it has internationalization and accessibility. The smaller API, higher performance, faster development of Dear Imgui is more important for me.
Some reported that moving from Qt to Dear Imgui resulted in a codebase three-time smaller.
It’s be helpful to have some concrete examples of where one might run into limits with the minimalist frameworks and why a larger framework is required to overcome those limits.
file open/save dialogs, i18n, drag and drop, image formats, web views, any sort of accessibility, themability that actually fits into native platforms, sometimes the ability to open new windows, many common controls that we just take for granted now that you have to implement yourself, sometimes limited amount of events you can reasonably handle based on the design of the api (IM gui's for instance).
I wouldn't say never use an minimalist framework. It can be handy for embedded debugging tools or for toy projects. But I wouldn't use one of these things for an application that I thought might have a few thousand users and some sort of life span.
Thanks for the list. I'll keep these in mind for my next GUI project. I've used Qt a few times for hobby projects, but was thinking about trying something else for my next GUI project.
Tables, tree views, popup menus, floating / docking windows, flexible layouts, file dialogs, animations.
IUP, which this wraps, does have most (all?) Of those
Two words: internationalization and accessibility.