C++ UI Libraries(philippegroarke.com)
philippegroarke.com
C++ UI Libraries
https://philippegroarke.com/posts/2018/c++_ui_solutions/
139 comments
I consent with you that many pros and cons are rather subjective and pros/cons depend on the specific use case. On the other hand, I like having a list of all these libraries with their supported platforms, license and a screenshot. This alone gives a pretty good overview of what's there. Not all pros/cons are subjective (e.g. having a GUI wysiwyg editor is definitely a pro for some use cases). Anyway, thanks for sharing your view and thanks for sharing this comprehensive overview.
Even the list of platforms is kinda pointless here, as Dear ImGui doesn't really support any platform itself. You're expected to write a glue yourself, with some examples for popular libraries/frameworks/engines being provided for your convenience (and those examples alone already go further than just four platforms listed in the article).
On the other hand, Qt is a whole framework itself which already handles all this stuff for you, which makes a lot of stuff easier, but then you're of course limited to what's supported by Qt.
On the other hand, Qt is a whole framework itself which already handles all this stuff for you, which makes a lot of stuff easier, but then you're of course limited to what's supported by Qt.
Yes it is useful to have a list of everything, but I feel like I can get a list like this in about a half hour with Google. What I can't get in a half hour is a summary of the problems people have had with particular framework, or the reasons why they chose to start using or stop using a particular framework.
The picture from the beginning is very exciting and optimistic. To pick on ImGui again, it's easy to get started--but I know there are some issues with larger projects, some things that are hard to do in immediate mode, etc.
The picture from the beginning is very exciting and optimistic. To pick on ImGui again, it's easy to get started--but I know there are some issues with larger projects, some things that are hard to do in immediate mode, etc.
Agreed. I use Dear ImGui, I like it, but it's certainly not a general purpose tool which you can replace Qt with (or vice versa). It's a completely different project made for different use cases, and "nothing jumps out to me" in the list of cons sounds a lot like "I just started using it and I love it".
> Cons: [...] I don’t like it
I found that reasoning funny for something like Qt that almost everyone knows, but as i was reading on and on, i found myself asking "why" to many of those cons (and some pros). I do not think this list is very useful really, it is mainly a link dump and the descriptions also seem to be taken from the sites, at least for the less popular ones. I'd prefer to see an actual review (even a single paragraph, it would help explain why "IDE?" is both a pro and con for U++) which go a bit more in detail than "ugly af" (which i disagree with, btw, i like how Fox Toolkit looks) and "sourceforge" (wth is the problem with a site's project being on sourceforge? It provides excellent tools for projects, not everyone has to monoculture themselves on GitHub).
Also it is a bit wrong. Both Motif and WTL are not dead projects, Motif is still getting updates (although it is mostly bugfixes) and WTL has new commits often with the original developer at the helm.
I found that reasoning funny for something like Qt that almost everyone knows, but as i was reading on and on, i found myself asking "why" to many of those cons (and some pros). I do not think this list is very useful really, it is mainly a link dump and the descriptions also seem to be taken from the sites, at least for the less popular ones. I'd prefer to see an actual review (even a single paragraph, it would help explain why "IDE?" is both a pro and con for U++) which go a bit more in detail than "ugly af" (which i disagree with, btw, i like how Fox Toolkit looks) and "sourceforge" (wth is the problem with a site's project being on sourceforge? It provides excellent tools for projects, not everyone has to monoculture themselves on GitHub).
Also it is a bit wrong. Both Motif and WTL are not dead projects, Motif is still getting updates (although it is mostly bugfixes) and WTL has new commits often with the original developer at the helm.
I'm a longtime user (15+ years) of wxWidgets in a commercial application. It's served us well during that time but lately it's been feeling more and more like our software looks outdated. Native UI is long touted as a pro but more and more software is eschewing the native look to stand out. Even Microsoft has been abandoning the win32 look in their win32 applications (Office, VS, etc.).
I found the linked page a few months back and was disappointed that there was no clear winner for someone that wants a nice, modern looking interface. JUCE looked nice but is weirdly focused on the niche audio applications field (and their website is so full of marketing copy it's hard to even get a feel for what it's like to use and how things fit together).
I'm a fan of the concept of IM GUIs in general (though pure immediate mode UI probably isn't appropriate for us for a variety of reasons) but Dear ImGui and most of the others just don't do the right UI paradigms to fit an application like ours (a thousand floating windows would drive our users insane).
We're at this weird place were game UI libraries look great (or can be made to) but aren't appropriate for information dense commercial applications, the available libraries designed for that use case look awful, and the big companies that have great UIs aren't sharing them with anyone.
I found the linked page a few months back and was disappointed that there was no clear winner for someone that wants a nice, modern looking interface. JUCE looked nice but is weirdly focused on the niche audio applications field (and their website is so full of marketing copy it's hard to even get a feel for what it's like to use and how things fit together).
I'm a fan of the concept of IM GUIs in general (though pure immediate mode UI probably isn't appropriate for us for a variety of reasons) but Dear ImGui and most of the others just don't do the right UI paradigms to fit an application like ours (a thousand floating windows would drive our users insane).
We're at this weird place were game UI libraries look great (or can be made to) but aren't appropriate for information dense commercial applications, the available libraries designed for that use case look awful, and the big companies that have great UIs aren't sharing them with anyone.
When I was at Autodesk we used QT for a lot of things. (I think Maya was built with it, and I know FormIt is). There's definitely some downsides to QT, but one of the nice things is that thematically it's very customizable with QSS. So you can get a nice blend of native w/ more modern customizations, or there's even the "quick" route which I never used but it looks like it's meant to be super modern.
> the big companies that have great UIs aren't sharing them with anyone.
Here are some "big companies" https://sciter.com/#customers and the library they use for their UIs.
Here are some "big companies" https://sciter.com/#customers and the library they use for their UIs.
IMHO, only Evernote stands out in this list. Most of the other companies seem to have trivial user interfaces requirements. The GUI for an antivirus product could be built with just about any framework.
"The GUI for an antivirus product could be built with just about any framework"
Not "any" as Section 508 is mandatory for example.
That really limits your options to Qt and Sciter from that list (if to consider style of their UI).
Qt is too large for them and not that convenient as they need. Yet DirectX (hardware accelerated) rendering is the must for high-DPI support.
And check this: https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o... . That is about 12 years of one application that is transitioned from Skeumorphism to Metro style UI without changing native code of UI.
Not "any" as Section 508 is mandatory for example.
That really limits your options to Qt and Sciter from that list (if to consider style of their UI).
Qt is too large for them and not that convenient as they need. Yet DirectX (hardware accelerated) rendering is the must for high-DPI support.
And check this: https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o... . That is about 12 years of one application that is transitioned from Skeumorphism to Metro style UI without changing native code of UI.
Juce works pretty well, their examples are just for niche audio applications.
What is wrong with Qt for this scenario?
What is wrong with Qt for this scenario?
Can you now write a JUCE app that doesn't wake up every 16 miliseconds or so, even when idling? It's horrible for any battery operated device.
It is a GPL library in non commercial form so I would guess the answer is yes. That's good to know though.
Well, if we count "fixing it yourself" as an answer, then of course - but at this point you could just write your own toolkit anyway ;) I have actually tried to take a look at what JUCE does there and it looks like their whole rendering path is strongly tied to constantly running timers. Reworking JUCE to sleep more doesn't look to me like a small patch - it's more likely to be some kind of architectural rework.
BTW. I know this only because the Pocket C.H.I.P used JUCE for its default launcher and I tried to investigate why does the launcher eat 5-8% CPU all the time even when idling in background. At the end I've "fixed" it by putting something like "max(200, duration)" instead of "duration" in the code inside JUCE that schedules timers. This makes the UI pretty laggy, but at least the device sleeps around 10 times longer than before :P
BTW. I know this only because the Pocket C.H.I.P used JUCE for its default launcher and I tried to investigate why does the launcher eat 5-8% CPU all the time even when idling in background. At the end I've "fixed" it by putting something like "max(200, duration)" instead of "duration" in the code inside JUCE that schedules timers. This makes the UI pretty laggy, but at least the device sleeps around 10 times longer than before :P
Desktop crossplatform development is a weird beast. Yeah you get to share a lot of code between platforms and it's easy to get 80% there, but getting a polished UI is a lot of work.
In some cases such as using JUCE for making audio plugins it's even desired to not have a native UI since users expect each plugin to have its own UI. But unless you are huge, like say Adobe, having a nice and polished cross platform UI for application development is simply not feasible.
After years I've come to the conclusion that the proper way of supporting multiple platforms is having native UIs and sharing application logic in any way you can between platforms. I think that's the idea behind Xamarin.
In some cases such as using JUCE for making audio plugins it's even desired to not have a native UI since users expect each plugin to have its own UI. But unless you are huge, like say Adobe, having a nice and polished cross platform UI for application development is simply not feasible.
After years I've come to the conclusion that the proper way of supporting multiple platforms is having native UIs and sharing application logic in any way you can between platforms. I think that's the idea behind Xamarin.
Even Adobe has bungled its cross-platform UI support/tooling a number of times. I think the reduced scope definitely helps though, but even in that scenario some problems seem to unavoidably surface.
Source: have written plugins for Adobe products for many years.
Source: have written plugins for Adobe products for many years.
What do you mean by "reduced scope"?
Actually JUCE has deep coverage of highly portable UI concepts as well. I think it compares favorably with QT.
I like JUCE architecture as probably more than other library.
I actually even considered JUCE as a backend for my Sciter: https://sciter.com/sciter-on-mac-with-juce-backend/
But the problem is that JUCE uses pure software rasterizer. That unfortunately does not work for high-DPI monitors. GPU acceleration is required for almost all modern UI applications.
I actually even considered JUCE as a backend for my Sciter: https://sciter.com/sciter-on-mac-with-juce-backend/
But the problem is that JUCE uses pure software rasterizer. That unfortunately does not work for high-DPI monitors. GPU acceleration is required for almost all modern UI applications.
It is unfortunate that the libui author very much insists on doing everything himself instead of encouraging a more community oriented development approach. The job is too big for any single person.
If that project was managed better it would be huge. Even by basically being unusable it still has so much interest.
If that project was managed better it would be huge. Even by basically being unusable it still has so much interest.
I can completely relate. Some contribution is good when a project has established a few regular contributers, but a lot of open-source maintenance these days is babysitting drive-by programmers. In my experience, people's code can be so bad, it would take 2x the time to fix than to implement myself with nothing but a brief feature request from them instead.
I look back into that library and it’s derivatives every other month hoping.
It’s intuitive to use as is, though I haven’t honestly look at the design.
It could be great.
It’s intuitive to use as is, though I haven’t honestly look at the design.
It could be great.
Wait, what's stopping the community from helping out? It is open source, right?
Well if PR don’t get merged because the author plans on redoing that part of the lib or does not fit with their “vission” that pretty effectively kills the community help.
isn't JUCE single-developer too? it's been around forever and seems pretty featureful
Started off as such (Jules Utility something something), but now there is a team of at least 3 or 4 working on it.
Regarding GTK/gtkmm:
> - building & linking is hell
Building GTK itself perhaps. I haven't tried that. However, to use it in an application it appears that adding a couple lines to your CMakeLists.txt suffices[1]. I've used GTK (in C) in the past and had no problems with the "building the application" part.
> - GNOME
An explanation for why you see GTK's association with GNOME as a con would be appropriate.
> - looks meh
How it looks, depends on the theme used. However, I do agree that it "looks meh" with Adwaita (the currently default theme).
[1] https://wiki.gnome.org/Projects/gtkmm/UsingCMake
> - building & linking is hell
Building GTK itself perhaps. I haven't tried that. However, to use it in an application it appears that adding a couple lines to your CMakeLists.txt suffices[1]. I've used GTK (in C) in the past and had no problems with the "building the application" part.
> - GNOME
An explanation for why you see GTK's association with GNOME as a con would be appropriate.
> - looks meh
How it looks, depends on the theme used. However, I do agree that it "looks meh" with Adwaita (the currently default theme).
[1] https://wiki.gnome.org/Projects/gtkmm/UsingCMake
In my opinion Adwaita dark looks pretty good. Since I'm currently building a Gtk3 app in Go, I'm very curious: Which theme would you prefer for a modern desktop application?
With GNOME I use Arc-Darker. With i3 I use Numix. I generally prefer Numix, but for some reason it looks weird e.g. with nautilus.
wxWidgets seems to strike the best balance between documentation, activity, and having native widgets.
It's also true that the API is weird, and some of the wrapped native APIS are deprecated, or work weirdly with modern features.
Now if the qt branch for Linux was stable...
But really, C++ has so much choice compared to say, Rust.
It's also true that the API is weird, and some of the wrapped native APIS are deprecated, or work weirdly with modern features.
Now if the qt branch for Linux was stable...
But really, C++ has so much choice compared to say, Rust.
Yeah, of all the popular C++ tookits listed in the site, my personal "favorite" is wxWidgets (favorite in quotes because i do not really like it, it is just the one i found myself being more comfortable with). We're using Qt at my current job and while i'm ok with it, i still like working with wxWidgets more than Qt (even if Qt is certainly more polished).
I found documentation fine with both toolkits, although i really like that wxWidgets's docs are in CHM format so i can quickly search and scan them locally with a handy tree of contents at the side. With Qt i have to use the online docs and searching goes through Google which slows things down (...there might be some offline docs at the Qt site to download, but i couldn't find it).
I found documentation fine with both toolkits, although i really like that wxWidgets's docs are in CHM format so i can quickly search and scan them locally with a handy tree of contents at the side. With Qt i have to use the online docs and searching goes through Google which slows things down (...there might be some offline docs at the Qt site to download, but i couldn't find it).
Qt Assistant(Offline doc browser) comes with Qt. You can also use Zeal(supports offline docs for JS/HTML/CSS/TS/Vue/..., OpenGL, Qt, and many others)
It does, but it doesn't contain the Qt documentation. It only has documentation for itself.
It might be that something is missing, i just cannot figure out what.
It might be that something is missing, i just cannot figure out what.
You are missing some documentation packages or they somehow went missing from the index. You can add them (.qch files) in the settings menu of Assistant.
If you install Qt through the installer (which would be the main way of getting it on Windows), your installation should have a "Docs" folder containing HTML files.
Many Linux distros package it separately, e.g. on OpenSuSE it's in "libqt5-qtdoc" and its subpackages.
Many Linux distros package it separately, e.g. on OpenSuSE it's in "libqt5-qtdoc" and its subpackages.
I didn't installed Qt myself, it is part of the repository (gamedev, we put everything in the repository :-P). Perhaps i'll try to install the same version of Qt somewhere separately and see if the docs are there.
Look for qt-doc as separate package in your distro. It's size 30Mb, so many distro split it into dedicated package.
I'm curious if it might make sense to port FCL (FreePascal / Lazarus take on VCL replacement) to C++.
Note that the Free Pascal/Lazarus equivalent to VCL is two libraries: FCL and LCL, with the former being part and developed by the developers of Free Pascal and the latter being part and developed by the developers of Lazarus (while there is an overlap, they are two different projects with different teams). FCL is also used by other projects (e.g. FPGUI uses FCL but not LCL) and if you install just Free Pascal you only get FCL, not LCL.
With that in mind and considering the context i guess you meant LCL.
Now, LCL would be very hard to port to C++ because it is really built around Object Pascal features like a rich RTTI with explicitly exported properties, component streaming, "default" accessors, enums, sets, object instance method pointers and other features that C++ does not support at a language level. In C++ Builder the VCL is written in Object Pascal (and it even includes a Pascal compiler and linker), the language has been extended considerably to support Object Pascal-isms (e.g. __published section in classes, __property declarations, __fastcall calling convention that is Delphi-compatible, __delegate types for pointers to object instance methods, etc) and the runtime and library are written with some internal representation in mind (e.g. Pascal sets and strings are exposed to C++ using classes that have the same memory layout as the values the Pascal compiler creates). Of course some of those could be avoided if you do not care about a 1-to-1 port of FCL/LCL and compatibility with it, but still a lot of the functionality comes out of core Object Pascal features (since Borland had full control of the language, they designed both the language and API to complement each other, which is why it feels so weird in C++ Builder).
Beyond that, you'd really need an IDE with a visual designer like Lazarus as the entire API is designed to be manipulated in a visual way (e.g. while LCL does provide Qt/Gtk/Java/etc layout managers, they are really an afterthought in case you really want them and layout is mainly handled via anchors which have a dedicated visual editor - similarly the API uses a lot of custom collections that are meant to be edited with collection-specific editors in the IDE).
You could use Lazarus for that, but since Lazarus is meant to work with Free Pascal and does a lot of parsing (it essentially keeps the entire codebase, including all units and libraries as parsed nodes in memory) and automatic code editing (e.g. filling in the handler methods when you double click an event handler - or a component which fills the default event handler, navigating around the code, refactoring, removing empty handler methods, etc) you'll need to teach it enough C++ to be similar to writing a C++ compiler.
You could avoid the "porting to C++" part and using FCL/LCL directly from C++ in a similar way to what C++ Builder does... but then you'd need to convince some C++ compiler to include C++ Builder-like extensions and Free Pascal's developers to cooperate with said compiler's developers to ensure compatibility. You'd still need the Lazarus-needs-to-learn-C++ par though.
You could avoid all the above by making an "LCL inspired" (really, VCL inspired) library which vaguely resembles LCL for those who already know it but sticks with C++'s strengths. It wont be LCL/VCL though and wont take advantage of Lazarus, at which point you might as well make something that avoids the warts that LCL/Lazarus has.
Ah btw, did i mention the part where since LCL is essentially a cross-platform VCL reimplementation and VCL was designed only with Windows in mind, it has to implement a small subset of the Windows API for every platform and widgetset it supports? Yeah, are you sure you want to port that part too?
Honestly i'd love to see C++ Builder-like support in Lazarus and LCL, but practically i think it would be easier to make a new C++ Builder-like tool from scratch than make Lazarus, LCL, Clang (or GCC) and Free Pascal work together - even if we ignore the social/political side of convincing the developers behind those projects to work with the other projects.
With that in mind and considering the context i guess you meant LCL.
Now, LCL would be very hard to port to C++ because it is really built around Object Pascal features like a rich RTTI with explicitly exported properties, component streaming, "default" accessors, enums, sets, object instance method pointers and other features that C++ does not support at a language level. In C++ Builder the VCL is written in Object Pascal (and it even includes a Pascal compiler and linker), the language has been extended considerably to support Object Pascal-isms (e.g. __published section in classes, __property declarations, __fastcall calling convention that is Delphi-compatible, __delegate types for pointers to object instance methods, etc) and the runtime and library are written with some internal representation in mind (e.g. Pascal sets and strings are exposed to C++ using classes that have the same memory layout as the values the Pascal compiler creates). Of course some of those could be avoided if you do not care about a 1-to-1 port of FCL/LCL and compatibility with it, but still a lot of the functionality comes out of core Object Pascal features (since Borland had full control of the language, they designed both the language and API to complement each other, which is why it feels so weird in C++ Builder).
Beyond that, you'd really need an IDE with a visual designer like Lazarus as the entire API is designed to be manipulated in a visual way (e.g. while LCL does provide Qt/Gtk/Java/etc layout managers, they are really an afterthought in case you really want them and layout is mainly handled via anchors which have a dedicated visual editor - similarly the API uses a lot of custom collections that are meant to be edited with collection-specific editors in the IDE).
You could use Lazarus for that, but since Lazarus is meant to work with Free Pascal and does a lot of parsing (it essentially keeps the entire codebase, including all units and libraries as parsed nodes in memory) and automatic code editing (e.g. filling in the handler methods when you double click an event handler - or a component which fills the default event handler, navigating around the code, refactoring, removing empty handler methods, etc) you'll need to teach it enough C++ to be similar to writing a C++ compiler.
You could avoid the "porting to C++" part and using FCL/LCL directly from C++ in a similar way to what C++ Builder does... but then you'd need to convince some C++ compiler to include C++ Builder-like extensions and Free Pascal's developers to cooperate with said compiler's developers to ensure compatibility. You'd still need the Lazarus-needs-to-learn-C++ par though.
You could avoid all the above by making an "LCL inspired" (really, VCL inspired) library which vaguely resembles LCL for those who already know it but sticks with C++'s strengths. It wont be LCL/VCL though and wont take advantage of Lazarus, at which point you might as well make something that avoids the warts that LCL/Lazarus has.
Ah btw, did i mention the part where since LCL is essentially a cross-platform VCL reimplementation and VCL was designed only with Windows in mind, it has to implement a small subset of the Windows API for every platform and widgetset it supports? Yeah, are you sure you want to port that part too?
Honestly i'd love to see C++ Builder-like support in Lazarus and LCL, but practically i think it would be easier to make a new C++ Builder-like tool from scratch than make Lazarus, LCL, Clang (or GCC) and Free Pascal work together - even if we ignore the social/political side of convincing the developers behind those projects to work with the other projects.
C++ Builder had all those language extensions because it wanted to be binary compatible with Delphi units, including VCL. This is not the goal here.
If you don't care about that, most of the things that you've listed can be mapped to modern C++ just fine, with std::string for strings, std::function for function pointers etc. In fact, that's an advantage of starting with a higher-level API - because it has things like properties explicitly, they can be mapped to different languages in different ways, including cases where the mapping is one-to-many - e.g. property to a pair of method overloads in C++.
This all could be driven by a code generator, which would also produce the data structures to drive RTTI. Think about WinRT - single ABI and object model, multiple language mappings from JS to VB to C++. Delphi object model is actually somewhat similar to that, and even simpler in some ways (e.g. no refcounting). For a Delphi library mapped to C++, the end result could look a lot like C++/WinRT.
IDE support is tricky, yes. You really, really don't want to constantly parse/generate C++, there's just too many corner cases. But if you just take the form designer, it doesn't need to know anything about code - it just needs to understand components and properties, and spit out some representation that a code generator (or even a runtime loader) can turn into an actual object graph. That should suffice for layouts. Event handlers would have to be wired from code, but that's not a big deal.
As far as legacy warts, well, the only other framework we currently have that uses native widgets everywhere is wxWidgets, and its design was originally influenced by MFC of all things, so... It would be nice to have a clean ground-up design for modern idiomatic C++, and accounting for all the modern desktop platforms - but it's a huge project, and unlikely to get far because of that. LCL, on the other hand, is already there, and is a proven and maintained codebase. If there's a way to take it and produce a C++ version, or even a C++ bridge to a Pascal implementation (given that FP can statically link, it could all be in a single shared library that exposes a C API, and its clients wouldn't even know that it's written in Pascal).
If you don't care about that, most of the things that you've listed can be mapped to modern C++ just fine, with std::string for strings, std::function for function pointers etc. In fact, that's an advantage of starting with a higher-level API - because it has things like properties explicitly, they can be mapped to different languages in different ways, including cases where the mapping is one-to-many - e.g. property to a pair of method overloads in C++.
This all could be driven by a code generator, which would also produce the data structures to drive RTTI. Think about WinRT - single ABI and object model, multiple language mappings from JS to VB to C++. Delphi object model is actually somewhat similar to that, and even simpler in some ways (e.g. no refcounting). For a Delphi library mapped to C++, the end result could look a lot like C++/WinRT.
IDE support is tricky, yes. You really, really don't want to constantly parse/generate C++, there's just too many corner cases. But if you just take the form designer, it doesn't need to know anything about code - it just needs to understand components and properties, and spit out some representation that a code generator (or even a runtime loader) can turn into an actual object graph. That should suffice for layouts. Event handlers would have to be wired from code, but that's not a big deal.
As far as legacy warts, well, the only other framework we currently have that uses native widgets everywhere is wxWidgets, and its design was originally influenced by MFC of all things, so... It would be nice to have a clean ground-up design for modern idiomatic C++, and accounting for all the modern desktop platforms - but it's a huge project, and unlikely to get far because of that. LCL, on the other hand, is already there, and is a proven and maintained codebase. If there's a way to take it and produce a C++ version, or even a C++ bridge to a Pascal implementation (given that FP can statically link, it could all be in a single shared library that exposes a C API, and its clients wouldn't even know that it's written in Pascal).
Yes, i already mentioned all that with <<You could avoid all the above by making an "LCL inspired" (really, VCL inspired) library which vaguely resembles LCL for those who already know it but sticks with C++'s strengths.>>
However,
> IDE support is tricky, yes. You really, really don't want to constantly parse/generate C++, there's just too many corner cases. But if you just take the form designer, it doesn't need to know anything about code
...as i also wrote, <<It wont be LCL/VCL though and wont take advantage of Lazarus, at which point you might as well make something that avoids the warts that LCL/Lazarus has.>>.
Lazarus and LCL (and Delphi and VCL) strength comes from both being designed with each other and the language in mind and a big part of the process is for the IDE to be able to understand the language and modify the code as you work with the visual tools. These weren't designed in isolation as independent components, they were meant to be one thing.
What you describe here:
> But if you just take the form designer, it doesn't need to know anything about code - it just needs to understand components and properties, and spit out some representation that a code generator (or even a runtime loader) can turn into an actual object graph. That should suffice for layouts. Event handlers would have to be wired from code, but that's not a big deal.
...is really what wxFormBuilder, Qt Creator and even Gtk's Glade do and significantly inferior to the experience of using Lazarus. Hell, it is significantly inferior to using something like Delphi or Borland C++ Builder from the mid-90s. In Delphi 1 (that is Windows 3.1 time) if you drop a button in a form and double click it, the IDE will generate a new method for you, update the class declaration to include that method (at the correct place), write the method body, associate the OnClick event with that method and focus the code editor window with the text editor cursor placed on an empty line between the method's "begin" and "end" keyword so you can start typing code right away. If you decide that this was a mistake, you simply leave it empty and once you save the file, the IDE will remove the method (and any other empty handler method), update the class declaration and remove the event association as if nothing happened.
What you write here with "Event handlers would have to be wired from code" is already making the tool you describe a worse user experience than a tool released almost 25 years ago. And "that's not a big deal"? Every time i have to wire events by hand manually at work where we use Qt (the supposedly "modern" toolkit), where i have to declare the handler methods (slots) in the class and write their bodies in the source file, ensure that the signature is the same as what the event expects, write the correct bindings in the class initialization and all that by hand, i'm thinking how much of that is a waste of time since with Lazarus that would be a double click on the event's name in the object inspector and the IDE would do all that manual labor for me.
No, trying to separate the IDE from the language and the API is going to produce a much worse experience. It doesn't matter much if you want to make that hypothetical C++ library compatible with Lazarus and FCL/LCL (i only mentioned that because it would be something one could think to take advantage of all the work the FCL and LCL developers have made - FCL is almost as old as Delphi and LCL is only a few years younger, both providing a rich framework after all). You can create a fresh C++-centric API that understands there are more platforms than Windows and takes advantage of C++ features found in most modern compilers.
But if you want to make something like Lazarus and LCL the IDE must understand the language, it must be able to update and work with your code, it must be designed with the API in mind and the API designed with the IDE in mind. You must consider the entire thing as a whole, not just in parts.
If anything, some of the issues i have with Lazarus in terms of user experience come from Lazarus and Free Pascal being two separate projects made by two separate teams.
However,
> IDE support is tricky, yes. You really, really don't want to constantly parse/generate C++, there's just too many corner cases. But if you just take the form designer, it doesn't need to know anything about code
...as i also wrote, <<It wont be LCL/VCL though and wont take advantage of Lazarus, at which point you might as well make something that avoids the warts that LCL/Lazarus has.>>.
Lazarus and LCL (and Delphi and VCL) strength comes from both being designed with each other and the language in mind and a big part of the process is for the IDE to be able to understand the language and modify the code as you work with the visual tools. These weren't designed in isolation as independent components, they were meant to be one thing.
What you describe here:
> But if you just take the form designer, it doesn't need to know anything about code - it just needs to understand components and properties, and spit out some representation that a code generator (or even a runtime loader) can turn into an actual object graph. That should suffice for layouts. Event handlers would have to be wired from code, but that's not a big deal.
...is really what wxFormBuilder, Qt Creator and even Gtk's Glade do and significantly inferior to the experience of using Lazarus. Hell, it is significantly inferior to using something like Delphi or Borland C++ Builder from the mid-90s. In Delphi 1 (that is Windows 3.1 time) if you drop a button in a form and double click it, the IDE will generate a new method for you, update the class declaration to include that method (at the correct place), write the method body, associate the OnClick event with that method and focus the code editor window with the text editor cursor placed on an empty line between the method's "begin" and "end" keyword so you can start typing code right away. If you decide that this was a mistake, you simply leave it empty and once you save the file, the IDE will remove the method (and any other empty handler method), update the class declaration and remove the event association as if nothing happened.
What you write here with "Event handlers would have to be wired from code" is already making the tool you describe a worse user experience than a tool released almost 25 years ago. And "that's not a big deal"? Every time i have to wire events by hand manually at work where we use Qt (the supposedly "modern" toolkit), where i have to declare the handler methods (slots) in the class and write their bodies in the source file, ensure that the signature is the same as what the event expects, write the correct bindings in the class initialization and all that by hand, i'm thinking how much of that is a waste of time since with Lazarus that would be a double click on the event's name in the object inspector and the IDE would do all that manual labor for me.
No, trying to separate the IDE from the language and the API is going to produce a much worse experience. It doesn't matter much if you want to make that hypothetical C++ library compatible with Lazarus and FCL/LCL (i only mentioned that because it would be something one could think to take advantage of all the work the FCL and LCL developers have made - FCL is almost as old as Delphi and LCL is only a few years younger, both providing a rich framework after all). You can create a fresh C++-centric API that understands there are more platforms than Windows and takes advantage of C++ features found in most modern compilers.
But if you want to make something like Lazarus and LCL the IDE must understand the language, it must be able to update and work with your code, it must be designed with the API in mind and the API designed with the IDE in mind. You must consider the entire thing as a whole, not just in parts.
If anything, some of the issues i have with Lazarus in terms of user experience come from Lazarus and Free Pascal being two separate projects made by two separate teams.
I don't strongly disagree with any of this. But again - we don't exactly have better options in C++, and especially not if you want native platform widgets. That is the baseline you should compare it to, not the experience of Delphi developers.
Creating a fresh C++-centric API is much harder than it sounds, and maintaining it over time, even more so. Go to any old online catalog that covers programming libraries, and look in its section for C++ UI stuff. There's scores of dead frameworks there that nobody has heard about. I don't see why it would be any different today with any project of that scope - so the only hope is to reduce the scope.
Creating a fresh C++-centric API is much harder than it sounds, and maintaining it over time, even more so. Go to any old online catalog that covers programming libraries, and look in its section for C++ UI stuff. There's scores of dead frameworks there that nobody has heard about. I don't see why it would be any different today with any project of that scope - so the only hope is to reduce the scope.
I agree that it is hard, both of my posts where about why it is hard to make something like LCL - be it exposing it to C++, making a direct port or making something inspired by it. However what you describe (which i assume was about "reducing the scope") isn't any different from what Qt and wxWidgets already do, especially on the design side (where LCL and Lazarus shine and is their main attraction). If you are going for something that is already sub-par (ie. worse than Lazarus) and doesn't even provide something better than existing solutions, why bother?
Qt doesn't use native widgets.
wxWidgets does, but I think even an automated conversion of LCL API would be better than what they have. It's a framework that's still stuck in C++ circa mid-90s.
wxWidgets does, but I think even an automated conversion of LCL API would be better than what they have. It's a framework that's still stuck in C++ circa mid-90s.
I'm talking in the context of working with the framework, not how the widgets are implemented. When i write "Qt and wxWidgets already do" it should be obvious i refer to something they both share, not something they differ. There are many differences in how all the mentioned frameworks, there isn't a point of comparing them down to that detail.
FWIW the majority of LCL is also designed in the mid-90s as it is really a clone of VCL which was designed with Windows in mind and has a lot of Windows-isms (e.g. TColor is 24bit only, no alpha channel, the extra byte is used - like with Windows - to encode a pseudocolor to be translated in one of user-defined colors ... from back when Windows allowed users to modify the color palette, but anyway).
FWIW the majority of LCL is also designed in the mid-90s as it is really a clone of VCL which was designed with Windows in mind and has a lot of Windows-isms (e.g. TColor is 24bit only, no alpha channel, the extra byte is used - like with Windows - to encode a pseudocolor to be translated in one of user-defined colors ... from back when Windows allowed users to modify the color palette, but anyway).
There is on problem with Lazarus approach.
IDE and visual form layout editors require specialized property editors. And amount of code for design time support is significant usually.
Yet, data produced by layout editors is not DIFF friendly. Ability to edit UI definitions in text forms is valuable for collaborative work. That's why Delphi/Lazarus is popular among INDIE developers but not in large companies.
IDE and visual form layout editors require specialized property editors. And amount of code for design time support is significant usually.
Yet, data produced by layout editors is not DIFF friendly. Ability to edit UI definitions in text forms is valuable for collaborative work. That's why Delphi/Lazarus is popular among INDIE developers but not in large companies.
I'm not sure what you have in mind, Lazarus (and AFAIK Delphi at least since version 7, most likely earlier too) saves the form as a text file which you can diff and i do that all the time when looking at changes in my code before submitting them. In fact the format is very readable and has a syntax like:
It only stores properties changed from their defaults which makes for very compact files and focusing on the stuff you have actually worked on.
If anything i find the XML files that other tools (like Qt Designer and wxFormBuilder) use harder to read.
object ScriptConsole: TScriptConsole
Left = 349
Height = 331
Top = 710
Width = 487
...
object Cmd: TEdit
Align = alBottom
end
...
end
It only stores properties changed from their defaults which makes for very compact files and focusing on the stuff you have actually worked on.
If anything i find the XML files that other tools (like Qt Designer and wxFormBuilder) use harder to read.
Ah, missed that one, thanks. Format looks like .frm files of VB6. And that's somehow closer to C++ (than Delphi) as widgets there are COM objects.
> Qt
> feature creep, the project
> uses ancient paradigms
> tends to overtake all your structures
> slow
> I don’t like it
Seriously?...
> feature creep, the project
> uses ancient paradigms
> tends to overtake all your structures
> slow
> I don’t like it
Seriously?...
I might be a wee bit biased because I work with Qt, but seriously, its breadth, quality, and documentation are why it's the quasi-standard for cross-platform UI programming. There is currently a discussion about the ownership model (I guess that is meant with "ancient paradigms") on the development mailing list. The ownership model isn't really among the top n problems during typical development in any case. There is also QML which is an extremely productive way to create hardware accelerated touch-friendly UIs. QML is widely used in embedded systems.
Can you point out some big desktop projects made with QT that run on macOS and/or Windows?
Autodesk uses it, e.g. for Maya and Eagle. Tableau. Some game engines use it for editor tooling, e.g. CryEngine.
In the open-source world: Krita, Scribus, Texmaker.
In the open-source world: Krita, Scribus, Texmaker.
The Dolphin emulator [0] and Krita [1] are two that come to my mind.
[0] https://dolphin-emu.org
[1] https://krita.org/en/
[0] https://dolphin-emu.org
[1] https://krita.org/en/
Dolphin just switched to it, too. They were on wxWidgets until recently.
There is a wiki page that lists some.
https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt
This is going to be a very limited list though, for instance there are dozens of applications in my domain that use Qt, and none of them are on this list.
https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt
This is going to be a very limited list though, for instance there are dozens of applications in my domain that use Qt, and none of them are on this list.
Allegorithmic Substance, Guitar Pro, https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt ...
I mean, just run a `find Qt5Core.dll` on windows or `find QtCore` on mac and see what's using Qt on your machine
I mean, just run a `find Qt5Core.dll` on windows or `find QtCore` on mac and see what's using Qt on your machine
Don't know if it is big or not, but Andy Brice's Perfect Table Plan is made with C++ and Qt, and IIRC, it runs on both Windows and macOS. It's been around for a long time and sells fairly well, according to posts on his blog, successfulsoftware.net , which I have been reading for a while. The blog also has many good posts about desktop software product development and marketing. Also, he's pretty much a one-man show, except fr some things, which shows it can be done.
Not terribly big, but big enough: LibrePCB (https://librepcb.org/)
Big in line count but not user count: Professional (the REALLY expensive stuff) 3D modeling and electronic design automation (EDA) packages.
I believe Maya and OBS use it
VLC, TeamViewer, Google Earth, Maya, VirtualBox.
Qbittorrent, Nuke and probably a lot of others.
[deleted]
(Answering myself)
DaVinci Resolve
DaVinci Resolve
Wireshark
I found it quite amusing, specially as the author failed to present a case -- and an example -- of what he perceives as being a modern paradigm.
I mean, how many projects he listed that supported any kind of UI design tool?
To me, Qt is still leaps and bounds beyond any alternative, not only in is design-centric tooling but also ease of use. Doubly so with Qt Quick. I find it quite strange that those aspects of Qt aren't readily noticed by someone who bothers to produce a list of C++ UI toolkits
I mean, how many projects he listed that supported any kind of UI design tool?
To me, Qt is still leaps and bounds beyond any alternative, not only in is design-centric tooling but also ease of use. Doubly so with Qt Quick. I find it quite strange that those aspects of Qt aren't readily noticed by someone who bothers to produce a list of C++ UI toolkits
Qt uses pointers, meta-objects, pre-precompiler, inheritance over templates, little use of the standard library... need I say more?
It is leaps and bounds beyond other things - but those leaps and bounds are into the past.
It is leaps and bounds beyond other things - but those leaps and bounds are into the past.
> Qt uses pointers
That statement lies somewhere between simplistic and out-right wrong. Qt uses pointers just like C++'s smart pointers use pointers.
https://doc.qt.io/qt-5/objecttrees.html
Moreover, Qt also provides a collection of smart pointers, which are used quite extensively by Qt.
https://wiki.qt.io/Smart_Pointers
> meta-objects, pre-precompiler
I fail to see the point of your complaint. Besides the fact that Qt's "pre-compiler" is used to transparently support stuff such as UI design tooling and Qt's resource system (which handles embedding images and i8n), Qt's meta-object system also adds the boilerplate code that implements stuff such as event loops, IPC, observers, and message-passing.
So, actually, what's your point?
This complaint is particularly absurd if we compare Qt with unquestionably modern technologies such as the Android stack, whose build process is jam-packed with precompiler steps and whose project trees are filled to the brim with XML-based DSLs.
> inheritance over templates, little use of the standard library
These complaints make absolutely no sense at all.
> need I say more?
...Yes? You actually failed to make a single point, let alone presented a rational argument to back your assertion.
> It is leaps and bounds beyond other things - but those leaps and bounds are into the past.
This jab is simply stupid, more so in light of your complains.
That statement lies somewhere between simplistic and out-right wrong. Qt uses pointers just like C++'s smart pointers use pointers.
https://doc.qt.io/qt-5/objecttrees.html
Moreover, Qt also provides a collection of smart pointers, which are used quite extensively by Qt.
https://wiki.qt.io/Smart_Pointers
> meta-objects, pre-precompiler
I fail to see the point of your complaint. Besides the fact that Qt's "pre-compiler" is used to transparently support stuff such as UI design tooling and Qt's resource system (which handles embedding images and i8n), Qt's meta-object system also adds the boilerplate code that implements stuff such as event loops, IPC, observers, and message-passing.
So, actually, what's your point?
This complaint is particularly absurd if we compare Qt with unquestionably modern technologies such as the Android stack, whose build process is jam-packed with precompiler steps and whose project trees are filled to the brim with XML-based DSLs.
> inheritance over templates, little use of the standard library
These complaints make absolutely no sense at all.
> need I say more?
...Yes? You actually failed to make a single point, let alone presented a rational argument to back your assertion.
> It is leaps and bounds beyond other things - but those leaps and bounds are into the past.
This jab is simply stupid, more so in light of your complains.
> little use of the standard library
FWIW this is a plus :-P i prefer working with Qt's containers and strings than STL (not specific to Qt really, i prefer almost any other container, string, etc library than STL, the API of which i find very unintuitive). Qt isn't just a library really, it is a framework you build your application around, when you use it you are supposed to buy in everything it does.
FWIW this is a plus :-P i prefer working with Qt's containers and strings than STL (not specific to Qt really, i prefer almost any other container, string, etc library than STL, the API of which i find very unintuitive). Qt isn't just a library really, it is a framework you build your application around, when you use it you are supposed to buy in everything it does.
So, please tell us :
- how do you implement reflection without either ugly macros or a precompiler?
- how do you implement metaclasses without a meraobject ? (e.g. how would you list all the methods or properties of a class)
- how do you implement a tree structure where the parents knows its children and the children know its parent in modern C++ (or Rust without unsafe :-)) ?
- how do you implement reflection without either ugly macros or a precompiler?
- how do you implement metaclasses without a meraobject ? (e.g. how would you list all the methods or properties of a class)
- how do you implement a tree structure where the parents knows its children and the children know its parent in modern C++ (or Rust without unsafe :-)) ?
Didn't you know that declarative, binding-oriented, hardware-accelerated, scene-graph based GUIs are both based on ancient, completely outdated paradigms, and slow?
And even besides QML, stuff like QGraphicsScene isn't really what I would call slow for CPU-based 2D graphics. It's good enough to be the rendering system for e.g. ECAD design tools.
And even besides QML, stuff like QGraphicsScene isn't really what I would call slow for CPU-based 2D graphics. It's good enough to be the rendering system for e.g. ECAD design tools.
While lacking in lots of built-in UI widgets, I use Cinder like a UI library. https://libcinder.org/ Perhaps "graphics library" would be a better descriptor and explains why I didn't find it on the list. But with mouse/touch, images, audio, video, etc. support, "graphics library" seems too narrow of a description. Maybe it's better to think of as a GUI library without a lot of commitments to the usual set of GUI widgets.
I used Cinder on a couple of projects and it's great for what it is. It would be a solid start for making your own UI library, but that is a considerable task.
Cinder looks neat. I'm curious though, the only packages it offers are for Windows or OS X. Do you know if it supports Linux at all?
I've used it on Linux (Raspberry Pi for my case) just fine. Guides here if you need it: https://www.libcinder.org/docs/guides/linux-notes/index.html
Thanks! I'll give that a try.
It does, yeah. They don't distribute pre-built linux packages, but most distros do.
Come on, man; if you're gonna allude to the awesomeness of a project's website, the least you could do is actually link to it!
For those as curious as I was:
Amulet: https://www.cs.cmu.edu/afs/cs.cmu.edu/project/amulet/www/amu...
Yzone: http://lifesoft.chat.ru/yzone/
For those as curious as I was:
Amulet: https://www.cs.cmu.edu/afs/cs.cmu.edu/project/amulet/www/amu...
Yzone: http://lifesoft.chat.ru/yzone/
Ah cross-platform UI libraries, when you want the user experience of Electron with the convenience and safety of C++.
This is beyond ignorant. I can create a tiny fast GUI with no dependencies using fltk in 1/1000th the size that runs with zero lag or latency.
It might be nostalgia, but I kinda miss writing simple stupid looking in practice fixed size and screen ratio win32-api apps.
It was so simple compared to how things work nowadays.
It was so simple compared to how things work nowadays.
You forgot performance and resource utilization.
It seems like native desktop app development is getting harder simply because fewer people are doing it; web apps seem to be the future.
Less investment -> less modernization -> less usage -> even less investment
Less investment -> less modernization -> less usage -> even less investment
Why not use dead projects ? I like TurboBadger for example.
It is pretty feature complete and the code base is well developed. so changes and/or fixes can be done quite easily.
It is pretty feature complete and the code base is well developed. so changes and/or fixes can be done quite easily.
Sciter is fantastic, and honestly I don't get it why being closed source is a con.
In fact, both 'commercial license / closed source' statements are not quite true - one may link against the precompiled dll for free, even in commercial apps (as cheap as that could be), while commercial licenses, starting from fair $310 (a lifetime license!), are there for those who need static linking, dedicated support and, mind you, access to the sources.
But even free users can expect a welcoming and timely response from the author (Sciter is a one-man affair). I, for one, never had a condescending or impolite reply to the dumbest of my questions.
Also, the article doesn't mention the fact that Sciter is more widespread than it might seem - for example, many Windows AV solutions, including Eset, Norton, Avast, Bitdefender and Comodo, use it as GUI engine.
In fact, both 'commercial license / closed source' statements are not quite true - one may link against the precompiled dll for free, even in commercial apps (as cheap as that could be), while commercial licenses, starting from fair $310 (a lifetime license!), are there for those who need static linking, dedicated support and, mind you, access to the sources.
But even free users can expect a welcoming and timely response from the author (Sciter is a one-man affair). I, for one, never had a condescending or impolite reply to the dumbest of my questions.
Also, the article doesn't mention the fact that Sciter is more widespread than it might seem - for example, many Windows AV solutions, including Eset, Norton, Avast, Bitdefender and Comodo, use it as GUI engine.
> honestly I don't get it why being closed source is a con
Transparency is a dependency of trust. If it ain't transparent, then it's not possible to trust it, end of story. This means that I'm going to be significantly disinclined to use a library if I can't see its source code (i.e. it's a binary blob with a header file). Sure, I could pay $310 for access to the source code so I can audit it myself (or hire someone to audit it for me)... or I could not spend that money and use something I can actually audit freely.
Same goes for static linking. I could spend $310 for the ability to statically link Sciter with my project... or I could not spend that money and use something I can include in any of my projects regardless of the license for that project.
Transparency is a dependency of trust. If it ain't transparent, then it's not possible to trust it, end of story. This means that I'm going to be significantly disinclined to use a library if I can't see its source code (i.e. it's a binary blob with a header file). Sure, I could pay $310 for access to the source code so I can audit it myself (or hire someone to audit it for me)... or I could not spend that money and use something I can actually audit freely.
Same goes for static linking. I could spend $310 for the ability to statically link Sciter with my project... or I could not spend that money and use something I can include in any of my projects regardless of the license for that project.
What sort of incentive would an indie developer who makes his living from sales of his software has to make his library malware and thus not only kill any current and potential future commercial endeavor, but also open himself to lawsuits from his own customers (among others)?
Maybe he wants to make a quick buck off users who don't pay for the source code?
Maybe he's a Latvian sleeper agent looking to infiltrate government software systems to boost the global potato market?
Maybe his machine was in turn infected by malware that's now able to spread via his compilers to any software he in turn compiles, Ken-Thompson-Trusting-Trust-style?
Maybe he sold it to someone else and the new owner is in one or more of the above categories?
These sorts of things happen all the time. Why should I expect this library to be an exception?
I mean, if you want to take that chance, go for it. Personally, given there are numerous other options out there, I'd rather stick to something with a FOSS license and source code that the general public (including myself) can audit (and potentially even maintain, for reasons that I outlined in response to the sibling comment).
Maybe he's a Latvian sleeper agent looking to infiltrate government software systems to boost the global potato market?
Maybe his machine was in turn infected by malware that's now able to spread via his compilers to any software he in turn compiles, Ken-Thompson-Trusting-Trust-style?
Maybe he sold it to someone else and the new owner is in one or more of the above categories?
These sorts of things happen all the time. Why should I expect this library to be an exception?
I mean, if you want to take that chance, go for it. Personally, given there are numerous other options out there, I'd rather stick to something with a FOSS license and source code that the general public (including myself) can audit (and potentially even maintain, for reasons that I outlined in response to the sibling comment).
> if you want to take that chance
No, I don't think I want, now that you've sown a seed of doubt in my mind..
It's just occurred to me that he well might be a covert princess who'll jump out of my laptop, disguised as a frog, and demand me to kiss him in order to dispel the evil spell!
No, I don't think I want, now that you've sown a seed of doubt in my mind..
It's just occurred to me that he well might be a covert princess who'll jump out of my laptop, disguised as a frog, and demand me to kiss him in order to dispel the evil spell!
[deleted]
[deleted]
Instead of paying $350 to a security analyst, I'd better pay them to an independent closed-source developer who makes a living from his software. Why would I trust some analyst more than the guy who works on his project with great care and dedication for over 10 years now?
> the guy who works on his project with great care and dedication for over 10 years now?
You're assuming he'll always work on his project with great care and dedication. Humans are, last I checked, mortal; even assuming he doesn't eventually tire of maintaining it and/or decide to sell it to someone else to maintain it (that someone else being by no means guaranteed to be neither negligent nor outright malicious), he'll almost certainly fall victim to the Great Garbage Collection Algorithm In The Sky at some point, and now all of a sudden you're tied to a library that now literally nobody can legally maintain (because the one person who had the rights to publish new versions is dead).
Even if he had the foresight to create an LLC or other business entity to abstract ownership away from his own person, that's still dependent on that LLC continuing to meaningfully exist. Ain't like companies are really immortal, either.
Why deal with that hassle when there are plenty of libraries that don't have that problem (because they're released under licenses that permit the users of those libraries to fork and continue their development should it be necessary to do so)?
If you're willing to pay an independent developer for a closed-source library, why not instead pay an independent developer for a not-closed-source library and get the best of both worlds?
> Instead of paying $350 to a security analyst, I'd better pay them to an independent closed-source developer who makes a living from his software.
If I'm paranoid enough to feel the need to pay someone else to audit my dependencies, FOSS would save me money; I'd only have to pay the $350 v. having to pay $350 + the source code price.
And no, just paying the original programmer is insufficient; the point of an audit is to establish trust in a system, and the original programmer has a pretty obvious conflict-of-interest if he's trying to, you know, sell me the software.
He could, of course, seek out a well-known third-party auditor to independently audit each build, thus being able to say "no need to take my word for it; this totally trustworthy other person checked it out and confirmed it's totally safe". While that's not quite as reassuring as a customer-initiated audit, it's certainly better than "just trust me, mmmkay?".
You're assuming he'll always work on his project with great care and dedication. Humans are, last I checked, mortal; even assuming he doesn't eventually tire of maintaining it and/or decide to sell it to someone else to maintain it (that someone else being by no means guaranteed to be neither negligent nor outright malicious), he'll almost certainly fall victim to the Great Garbage Collection Algorithm In The Sky at some point, and now all of a sudden you're tied to a library that now literally nobody can legally maintain (because the one person who had the rights to publish new versions is dead).
Even if he had the foresight to create an LLC or other business entity to abstract ownership away from his own person, that's still dependent on that LLC continuing to meaningfully exist. Ain't like companies are really immortal, either.
Why deal with that hassle when there are plenty of libraries that don't have that problem (because they're released under licenses that permit the users of those libraries to fork and continue their development should it be necessary to do so)?
If you're willing to pay an independent developer for a closed-source library, why not instead pay an independent developer for a not-closed-source library and get the best of both worlds?
> Instead of paying $350 to a security analyst, I'd better pay them to an independent closed-source developer who makes a living from his software.
If I'm paranoid enough to feel the need to pay someone else to audit my dependencies, FOSS would save me money; I'd only have to pay the $350 v. having to pay $350 + the source code price.
And no, just paying the original programmer is insufficient; the point of an audit is to establish trust in a system, and the original programmer has a pretty obvious conflict-of-interest if he's trying to, you know, sell me the software.
He could, of course, seek out a well-known third-party auditor to independently audit each build, thus being able to say "no need to take my word for it; this totally trustworthy other person checked it out and confirmed it's totally safe". While that's not quite as reassuring as a customer-initiated audit, it's certainly better than "just trust me, mmmkay?".
> he'll almost certainly fall victim to the Great Garbage Collection Algorithm In The Sky at some point, and now all of a sudden you're tied to a library that now literally nobody can legally maintain
Don't worry, you too are literally not going to be tied to such a library forever, you know :)
And I'm sorry to burst your bubble, but no software project, however open sourced and redundantly-maintained it is, is immortal either.
Don't worry, you too are literally not going to be tied to such a library forever, you know :)
And I'm sorry to burst your bubble, but no software project, however open sourced and redundantly-maintained it is, is immortal either.
Indeed, no software project is immortal, but a software project with a license that lets literally any user pick up where the upstream developer left off and maintain a fork to continue development is significantly less mortal than one without.
Closed source is a con, separate markup language guis are a con, 5MB binaries are a con.
That separate language can be learned in a few days and leave you wondering how one guy managed to make things more logical than a crowd of people around JS.
If 5MB is a con, what do you say about 30MB for Qt and ~100MB for Electron?
Also, could you please elaborate on the first statement?
If 5MB is a con, what do you say about 30MB for Qt and ~100MB for Electron?
Also, could you please elaborate on the first statement?
Markup languages for a GUI where isn't needed is a pain because you have a source of indirection when you could just pass the data that the UI library wants directly. Why have a separate text representation and if it must be there, why HTML and CSS? Json would allow you to give the information directly instead of using the convoluted rules of a system that has evolved over decades?
A text language that isn't just values being passed creates new rules and an opaque layer when it is completely unnecessary.
I don't know why Qt takes 50MBs or more for hello world or why anyone would use electron at all. At least Qt will run fast and not have lag and latency. Electron is just the worst of all worlds unless all someone knows is JavaScript.
A text language that isn't just values being passed creates new rules and an opaque layer when it is completely unnecessary.
I don't know why Qt takes 50MBs or more for hello world or why anyone would use electron at all. At least Qt will run fast and not have lag and latency. Electron is just the worst of all worlds unless all someone knows is JavaScript.
Sciter's author here...
"Markup languages for a GUI where isn't needed..."
You've missed big picture.
Markup language defines DOM structure (tree of UI objects). And you must have DOM in your application, either as tree of DOM nodes or tree of window nodes.
ANY UI application uses DOM tree in either form. And so ANY application uses some sort of markup language. Either binary one (e.g. Windows dialog resources) or text based ones (XAML,HTML,QML, etc). And HTML parsing is not significantly slower (https://www.codeproject.com/Articles/14076/Fast-and-Compact-...) then deciphering of binary formats. Yet the Accessibility ... that thing alone mandates DOM tree to be present.
Of course you can have UI where components are nailed down to pixel grids and colors but think about HighRes monitors, RTL languages, support of night/day theming, branding, etc.
Considering all that you will quickly understand that you need all three components: DOM, style system for the DOM and code that changes state of that DOM. Just to have all this modular an manageable on the long run.
"Markup languages for a GUI where isn't needed..."
You've missed big picture.
Markup language defines DOM structure (tree of UI objects). And you must have DOM in your application, either as tree of DOM nodes or tree of window nodes.
ANY UI application uses DOM tree in either form. And so ANY application uses some sort of markup language. Either binary one (e.g. Windows dialog resources) or text based ones (XAML,HTML,QML, etc). And HTML parsing is not significantly slower (https://www.codeproject.com/Articles/14076/Fast-and-Compact-...) then deciphering of binary formats. Yet the Accessibility ... that thing alone mandates DOM tree to be present.
Of course you can have UI where components are nailed down to pixel grids and colors but think about HighRes monitors, RTL languages, support of night/day theming, branding, etc.
Considering all that you will quickly understand that you need all three components: DOM, style system for the DOM and code that changes state of that DOM. Just to have all this modular an manageable on the long run.
> Markup language defines DOM structure (tree of UI objects). And you must have DOM in your application, either as tree of DOM nodes or tree of window nodes.
You've argued that UIs require a DOM. Ok, so UIs require a DOM.
That still fails to make a case for needing a separate proprietary markup language to define a DOM, let alone a XML-based one.
Even the Qt folks learned that lesson nearly a decade ago with the introduction of QML.
https://en.wikipedia.org/wiki/QML
You've argued that UIs require a DOM. Ok, so UIs require a DOM.
That still fails to make a case for needing a separate proprietary markup language to define a DOM, let alone a XML-based one.
Even the Qt folks learned that lesson nearly a decade ago with the introduction of QML.
https://en.wikipedia.org/wiki/QML
I don't think I've missed much.
> ANY UI application uses DOM tree in either form. And so ANY application uses some sort of markup language.
You are conflating DOM and markup language with heirarchy/dependencies. It isn't necessary to have a text language with lots of different overlapping rules and syntax.
> And HTML parsing is not significantly slower
It's not about speed, it's about unnecessary complexity just to get a layout heirarchy and dependencies.
> UI where components are nailed down to pixel grids and colors
That's a false dichotomy. UIs have been laying out their components without parsing text for almost half a century.
> ANY UI application uses DOM tree in either form. And so ANY application uses some sort of markup language.
You are conflating DOM and markup language with heirarchy/dependencies. It isn't necessary to have a text language with lots of different overlapping rules and syntax.
> And HTML parsing is not significantly slower
It's not about speed, it's about unnecessary complexity just to get a layout heirarchy and dependencies.
> UI where components are nailed down to pixel grids and colors
That's a false dichotomy. UIs have been laying out their components without parsing text for almost half a century.
> a text language with lots of different overlapping rules and syntax.
Could you elaborate more on this? What are those overlapping rules?
> unnecessary complexity just to get a layout heirarchy and dependencies.
I have no idea why you think it is so complex...
DOM element is this:
Could you elaborate more on this? What are those overlapping rules?
> unnecessary complexity just to get a layout heirarchy and dependencies.
I have no idea why you think it is so complex...
DOM element is this:
class Element {
weak_ptr<Element> parent;
vector<ptr<Element>> children;
map<...> attributes;
}
I'm talking about unnecessary complexity when laying out the gui, not implementation. There is no reason to introduce HTML with the various rules in various places, verbosity and indirection. It's a scenario that seems like when all you have is a hammer, everything looks like a nail.
> And you will see EXACTLY the same structure in any GUI framework/system.
I'm sure it works fine, but I wouldn't get stuck on thinking there is no other way.
> And you will see EXACTLY the same structure in any GUI framework/system.
I'm sure it works fine, but I wouldn't get stuck on thinking there is no other way.
"a hammer" you mean Electron and it's full scale browser, right?
"I wouldn't get stuck on thinking there is no other way"
There is a way, named "Dear ImGUI", that does not use DOM structure but rather recreates its on each paint event.
"I wouldn't get stuck on thinking there is no other way"
There is a way, named "Dear ImGUI", that does not use DOM structure but rather recreates its on each paint event.
You need to focus, no one is talking about electron. It's in its own world of nonsense.
> There is a way, named "Dear ImGUI"
I'm not talking about immediate GUIs (and they use a heirarchy for layout too of course). You put some example c++ and said every GUI has that same structure, which isn't necessarily true. A heirarchy doesn't have to be implemented with a tree of pointers.
I'm not saying these things can't work, but saying 'this is how it must be done' is just not true.
> There is a way, named "Dear ImGUI"
I'm not talking about immediate GUIs (and they use a heirarchy for layout too of course). You put some example c++ and said every GUI has that same structure, which isn't necessarily true. A heirarchy doesn't have to be implemented with a tree of pointers.
I'm not saying these things can't work, but saying 'this is how it must be done' is just not true.
But it is though. If you need to have accessibility support in your GUI, all the native accessibility APIs are based on trees so you're going to have to create that tree one way or another.
> every GUI has that same structure, which isn't necessarily true
I'd insist on EVERY here. Container holds list of children. Child holds reference to parent - typical tree implementation.
If you have in mind something else - please show.
I'd insist on EVERY here. Container holds list of children. Child holds reference to parent - typical tree implementation.
If you have in mind something else - please show.
You showed a few lines of C++. Even for heirarchy,this doesn't need to be a tree of pointers. It's not so bad if it is, but data can be represented as tables or arrays of attributes. Really in a ui the layout is about dependencies and doesn't strictly have to be hierarchy. It's not all that important, just saying that everything must be done in a certain way is ridiculous.
You only need to ship what you use. QtCore + QtWidgets is more like 15 MB. QtNetwork is another couple MB. The biggest part is QtWebEngine which contains Blink, the core of Chrome.
Edit: QtCore + QtQuick + QtQml should also be roughly 15 MB
Edit: QtCore + QtQuick + QtQml should also be roughly 15 MB
Why Qt takes 50 MBs for hello world?
Simple: because that is not true.
I have an application written for Qt and the Qt DLLs for Windows 16-bit are about 16 MB. (Core, Gui, Widgets, WinExtras, style and imageformats.) But, frankly, even if it were true, the disk size of the framework should be extremely low on a list of criteria. As others have noted, the pros and cons listed are not convincing.
Simple: because that is not true.
I have an application written for Qt and the Qt DLLs for Windows 16-bit are about 16 MB. (Core, Gui, Widgets, WinExtras, style and imageformats.) But, frankly, even if it were true, the disk size of the framework should be extremely low on a list of criteria. As others have noted, the pros and cons listed are not convincing.
I believe 50MB is an exaggeration, but not too far-fetched one. More of a problem is the proliferation and duplication of these DLLs all over the storage when many Qt-based apps are installed. A quick Everything query shows that right now I've got 290MB of Qt*.dlls on my drive.
Seems more like an issue with Windows and its ecosystem of nonfree software.
On most of the Unix-like distros, the maintainers fetch & compile the applications that they make available in the repositories. They can provide a few packages for the various Qt libs, and add these as dependencies to the hundreds/thousands of programs that use Qt. The Qt libs are only downloaded once regardless of whether you have 1 or 20 end-user Qt applications.
Dynamic loading and library updates aren't an issue since the distro maintainers recompile all the Qt-dependent applications whenever Qt has a major update. Older versions can be kept around for programs that haven't been updated in a long time (e.g. I have Qt4 installed on my system as a dependency even though Qt5 has been out for a long time), so there's little extra burden on developers. And with the exception of a few nonfree programs, the entire system works with one system-wide copy of any library.
Of course that doesn't fix the issue for Windows/macOS users, but there's an obvious and proven solution which works, and if main reason it doesn't work for Windows/macOS is because most developers for those platforms restrict the users of their software using nonfree licensing, it only seems fair to blame those ecosystems and OSs instead of blaming Qt.
On most of the Unix-like distros, the maintainers fetch & compile the applications that they make available in the repositories. They can provide a few packages for the various Qt libs, and add these as dependencies to the hundreds/thousands of programs that use Qt. The Qt libs are only downloaded once regardless of whether you have 1 or 20 end-user Qt applications.
Dynamic loading and library updates aren't an issue since the distro maintainers recompile all the Qt-dependent applications whenever Qt has a major update. Older versions can be kept around for programs that haven't been updated in a long time (e.g. I have Qt4 installed on my system as a dependency even though Qt5 has been out for a long time), so there's little extra burden on developers. And with the exception of a few nonfree programs, the entire system works with one system-wide copy of any library.
Of course that doesn't fix the issue for Windows/macOS users, but there's an obvious and proven solution which works, and if main reason it doesn't work for Windows/macOS is because most developers for those platforms restrict the users of their software using nonfree licensing, it only seems fair to blame those ecosystems and OSs instead of blaming Qt.
Correct me if I'm wrong, but Windows ecosystem doesn't forbid e.g. Java applications to use the same system-wide JRE, which has to be installed once, manually. It would be a nightmare if every Java app installed its own copy of JRE. Still can happen, like in case of Processing, but that's more of an exception.
> Correct me if I'm wrong, but Windows ecosystem doesn't forbid e.g. Java applications to use the same system-wide JRE, which has to be installed once, manually. It would be a nightmare if every Java app installed its own copy of JRE. Still can happen, like in case of Processing, but that's more of an exception.
uh... you were right in 2005. Nowadays the standard is for every app to ship its JRE - having to have to install a system wide JRE is part of the stuff that gave Java such a bad and bloaty reputation.
uh... you were right in 2005. Nowadays the standard is for every app to ship its JRE - having to have to install a system wide JRE is part of the stuff that gave Java such a bad and bloaty reputation.
> I believe 50MB is an exaggeration, but not too far-fetched one.
That's quite an inelegant way to state that you know you've made a false claim but yet you still stick by it.
That's quite an inelegant way to state that you know you've made a false claim but yet you still stick by it.
In the light of 290MB of scattered DLLs mentioned above, I believe that this is more than elegant way to advocate the guy who made this false claim - if you read carefully enough, you'll notice that it wasn't me. Care to check?
> I don't know why Qt takes 50MBs or more for hello world or why anyone would use electron at all
You have all my sympathy here :) Well, it should also be noted that 5MB is the size of Sciter's dynamic library. Compiled statically, there will be less contributing to the app's size.
As to markup languages, well, maybe, but I think they are a lot more expressive for things that are styled, positioned via constraints, dynamic and animated. That's completely different approach compared to predefined component libs like WinForms etc.
You have all my sympathy here :) Well, it should also be noted that 5MB is the size of Sciter's dynamic library. Compiled statically, there will be less contributing to the app's size.
As to markup languages, well, maybe, but I think they are a lot more expressive for things that are styled, positioned via constraints, dynamic and animated. That's completely different approach compared to predefined component libs like WinForms etc.
When it comes to embedded in particular, Qt has another major disadvantage: you have to pay royalties (!) to Qt, and worse yet, you have to deal with their slimy salespeople.
Paying for software is good, actually.
I don't mind paying for software. If it was a one-time payment for a royalty-free library, we'd pay a few thousand dollars, no problem. But this is a cost per device thereafter (in addition to the substantial up-front cost), which in embedded could mean crazy money. So we just hacked up GTK to meet our needs, for $0 per unit cost.
Until you have to maintain it, or find developers for it. From a business perspective there are a ton of reasons why just using Qt would be a good option.
If you're going to build a million of something, and you have a team of 50 programmers, you're already going to use a standard/well supported library. A licensing fee for each unit might be bad, but being able to hire another 10/20/100 people who are all familiar with that framwork already is a net benefit, even with the license cost. It's cheaper to just use Qt, all things considered.
If you're going to build a million of something, and you have a team of 50 programmers, you're already going to use a standard/well supported library. A licensing fee for each unit might be bad, but being able to hire another 10/20/100 people who are all familiar with that framwork already is a net benefit, even with the license cost. It's cheaper to just use Qt, all things considered.
GTK is both "standard" and "well supported". Besides, this is embedded, it's not something you'll be rolling out features to every week, nor would you have to deal with more than 2-3 hardware platforms (usually just 1 and minor revisions thereof) so the need for "support" is way overrated.
Unless you try to build it using the native rendering system on Mac OS. GTK only looks decent or native when used on Linux, and with a GTK-based windowing system.
If GTK looked respectable by default, and easily compiled for Mac OS (without X11) and Windows, then I'd have much more respect for it.
If GTK looked respectable by default, and easily compiled for Mac OS (without X11) and Windows, then I'd have much more respect for it.
Rendering on Mac OS seems pretty irrelevant for embedded devices.
Also a good point, thanks.
Yes, Qt is a good option in many cases, but that doesn't mean everyone not using it has made the wrong choice, all things considered. The parent posters company might be in a completely different situation or scale.
True, and a good point.
> Cons
> nothing jumps out to me
Why the fuck am I reading this article? I could easily write "nothing jumps out to me" or list a bunch of first-impressions of GUI libraries. But I can tell you off-hand a list of cons for Dear ImGui, and if you're interested there are plenty of Qt -vs- ImGui comparisons out there based on people who have actually switched and done a writeup. (Various people fall on both sides of this debate.)
https://deplinenoise.wordpress.com/2017/03/05/why-qt-and-not...
https://gist.github.com/bkaradzic/853fd21a15542e0ec96f726815...
There are definitely use cases out there where Dear ImGui is a clear winner over Qt, and vice versa, and if you're going to compare GUI frameworks I would expect to want to know more about them.
I have a big ole' bag of Google Docs that contain comparisons like this, but I sure as hell ain't gonna share them because they're full of subjective declarations and I stop evaluating an option as soon as I've figured out it doesn't meet my needs.