C++ UI Libraries
philippegroarke.com
philippegroarke.com
> 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.
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.
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.
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 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.
Here are some "big companies" https://sciter.com/#customers and the library they use for their UIs.
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.
What is wrong with Qt for this scenario?
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
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.
Source: have written plugins for Adobe products for many years.
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.
MacOS: Skia/OpenGL, optionally CoreGraphics. Native windowing.
Linux: Cairo, optionally Skia. GTK window primitives.
If that project was managed better it would be huge. Even by basically being unusable it still has so much interest.
It’s intuitive to use as is, though I haven’t honestly look at the design.
It could be great.
> - 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).
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.
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).
It might be that something is missing, i just cannot figure out what.
Many Linux distros package it separately, e.g. on OpenSuSE it's in "libqt5-qtdoc" and its subpackages.
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.
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.
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.
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).
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.
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.
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.
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).
> feature creep, the project
> uses ancient paradigms
> tends to overtake all your structures
> slow
> I don’t like it
Seriously?...
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
It is leaps and bounds beyond other things - but those leaps and bounds are into the past.
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.
- 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 :-)) ?
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.
In the open-source world: Krita, Scribus, Texmaker.
I mean, just run a `find Qt5Core.dll` on windows or `find QtCore` on mac and see what's using Qt on your machine
DaVinci Resolve
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.
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.
For those as curious as I was:
Amulet: https://www.cs.cmu.edu/afs/cs.cmu.edu/project/amulet/www/amu...
It was so simple compared to how things work nowadays.
Less investment -> less modernization -> less usage -> even less investment
It is pretty feature complete and the code base is well developed. so changes and/or fixes can be done quite easily.
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.
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?
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.
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.
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.
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.
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.
That's quite an inelegant way to state that you know you've made a false claim but yet you still stick by it.
Edit: QtCore + QtQuick + QtQml should also be roughly 15 MB
"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.
> 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.
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;
}
> 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.
"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.
> 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.
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.
Once again: IAccessibility mandates tree organization of your UI. You can do whatever you want but your UI framework MUST expose UI structure as a tree.
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.
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.
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?".
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.
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).
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!
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 GTK looked respectable by default, and easily compiled for Mac OS (without X11) and Windows, then I'd have much more respect for it.