Leaving The Qt Company
lists.qt-project.org
lists.qt-project.org
1. Performance that matches native speeds
2. Single codebase for multiple platforms (without relying on web technologies)
3. Not limited with a single language (has bindings to all major languages)
4. The core is written in a performant language (C++)
But recent developments in UI programming is sidelining frameworks like Qt with some really good innovations.
- Like React/React-native ecosystem pioneered the component based declarations of UI elements.
- Flutter pushed it to all platforms with Skia as the rendering engine
- Jetpack Compose is pushing it with a better language (Kotlin)
- State management had matured a lot with redux style immutable stores
The irony is even with all these recent developments there isn't a single UI framework that took the best parts of older frameworks like Qt and combined it with the recent ideas from Flutter and Jetpack-compose!
If it did it all, the multi-platform support is handicapped. Either the native strategy becomes an afterthought or the Web becomes an afterthought, hurting accessibility, etc.
We still have a long way to go in cross-platform UI frameworks :)
https://gitlab.com/eql/lqml/-/tree/master/examples/advanced-...
There's also performance issues with large amount of code, and last I checked, Qml doesn't really mix well with the traditional Qt widget and protocols (i.e. sometimes things are reimplemted in Qml under similar names, but with different behaviors)
What? Isn't HTML the daddy of declarative languages for UI ?
Not really. HTML is a way to create documents. It's closer to latex than QML. HTML + CSS + JS is used to create UIs, but it definitely does not match the capabilities of something like QML.
- CSS is used for styling, it is important but is not required.
Don't get me wrong, i think QML and XAML are cool and all, but HTML did this a long time ago.
What do you mean? Qt,WPF, Flex was doing UI with an XML syntax language before React existed, some people prefered doing things by hand instead of rag and drop back then too. The "components" were named Controls or Widgets and the Web still is a inferior pile of shit because in this old tooljits when you needed say a custom DataGrid widget you extended the existing one and where in Web you start from Zero with divs,inputs and buttons.
However, what's less excusable is thinking React components are somehow equivalent to XML: React components are a lot more than bits of JSX (components very often don't contain any JSX, it's an optional syntax extension, not a fundamental part).
There's very little in common between React components and the XML definitions used by Qt,
> UI with an XML syntax language
If you're interested in learning a bit about how React works, I'll start you off with this: React doesn't really do UI directly at all. It isn't layout-aware, layout is handled by the rendering target: e.g. DOM+CSS for the ReactDOM rendering lib, HTML+CSS for the ReactDOMServer rendering lib, UIKit for the RN iOS rendering lib, etc.
> I'm deeply familiar with React
I'm not trying to be snarky here but... React is not declarative.
Though it's good you highlighted that as that is essentially the fundamental difference here: WPF/QT are declarative, CSS is declarative, UIKit is (mostly?) declarative, HTML is declarative(-ish). React components aren't.
It's a far cry from an immediate mode API where you are making draw calls.
And it's not really representing UI: that's the main point here. Layout is decoupled; it's only really representing front-end logic and state.
I liked this about react, you create a render function and render your stuff. It is miles of head or the angular horrible architecture but the Web needs basic components implemented naively that developers can extend and not start every time from Zero with divs and other basic stuff.
To cut the explanation short, the former means while initial UI state was declarative (with XML), runtime mutations of UI were mostly imperative with a binding turing complete language.
The recent Component based model of composing UI - the runtime mutations of the elements are expressed as state updates inside the UI declarations itself(and declarations are usually done with a turing complete language)
is pretty much how Qt does it with QML (released in 2011), except that instead of requiring explicit function calls, the variables are themselves reactive so that:
Button { text: "foo" + counter.value }
Compos ability for me means I can make a big component by combining smaller ones, what does it mean to you?
Extensibility is the important part, you can get a DataGrid and add 10 lines of code to add some feature to it and you inherit everything from the base component, you get it all: the performance, the events, the accessibility. In web I only see shitty implementation that fail in different ways, even the YouTube search + dropdown input fails sometimes and remains open until you reload the page, a ton of Google "geniuses" can't implement a shitty component with all their languages and frameworks.
I personally like about react the functional part of it and not the JSX part, that is sugar syntax, though when doing complex stuff the functional part brke and you had no choice then get your hands dirty and find workarounds and do ugly stuff.
Most business work is still done with mice. Everybody thought fingered mobile would displace mouse-oriented UI's, but that was a bad prediction. Let's do open-source GUI's right this time. (Could QML be reworked to XML and made open-source?)
I doubt Chrome will stop using Skia, though Google can always do something akin to a fork or name-change that will break all existing apps.
Highly doubtful that will happen.
What "recent ideas" do you find in Jetpack Composer, Flutter and React Native that Qt lacks? These tools let you write apps with a nice user interface for Android exactly like Qt; supporting Kotlin, Dart, Javascript etc. besides C++ and various Qt language bindings is useful, but not necessarily superior.
why don't you consider NeXTSTEP from 1988 on to the present day in macOS UIKit?
1 is no longer an advantage since C++ is no longer a desirable language for UI engineers, largely because UI went from desktop to mobile and web which created an opportunity to disrupt the status quo
2 is no longer trendy either as functional programming becomes more popular. People realized they can be declarative in real programming languages and don't have to turn UI into a bunch of config files.
Actually I find this to be a serious pain point. Qt leans heavily on C++ features for core parts of its API (subclassing to create new widgets, for instance), and has its own C++ pre-processor. Getting to work in a different language in any capacity greater than "toy demo" is insanely hard - PyQt is probably the only success story here. I don't believe I have ever encountered a "real" program that uses Qt that was not written in C++ or Python.
2. You will need a big amount of hacks to make your project work on different platforms. Especially if you do something fancy.
Not to mention serious licencing issues.
>You will need a big amount of hacks to make your project work on different platforms. Especially if you do something fancy.
Having done Windows-Linux Qt, I haven't noticed needing "hacks" (unless you count the hacks necessary to build anything on Windows at all cuz the OS wasn't meant for programming ;p).
The fanciest thing I've done is theming (light, dark, etc.), which Qt doesn't seem to support natively, and which is difficult to do sanely without some "hacking".
>Not to mention serious licencing issues.
What issues? Is it just that it's LGPL, or what?
Light/dark theming should be easy with stylesheets.
On top of that, priorities are just different now. I spent an afternoon chasing down why QtCore has incomplete or missing methods for handling JSON documents (TLDR: "won't fix"), but I get a constant stream of marketing email promoting their new in-app advertising structure. And now there's a speech recognition engine?
I'm just done with it all. Guess I need to learn React.
Their bad licencing made sense back in the day. But they now face strong competition and instead of moving to a more open licence system, they seem to be doubling down. They don’t seem to understand that not only they aren’t the only framework in town anymore, they are currently worse than much better licenced systems.
As a Linux user, do tell me what the "native" solution is that I should be using! I love performance.
What does it feels like to spit random beliefs out of your hat and state them as truth? Native doesn't even mean anything, there really is something wrong going on on the mental models people have when talking about GUIs. IIRC QT use GDI+ on Windows for drawing 2D GUIs, which is mostly CPU based. And its shows in many tasks, see e.g. the strokePoly40 https://blend2d.com/performance.html Chromium use Skia and gecko use webrender, those are much much much faster on average. In fact the web has more FPS than native libraries in general.
I understand that people do things for reasons, but this situation looks pretty sad to me.
[0]: https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...
>All software changes in Qt will still be available at as Open Source as required by our contract – maybe with a delay of 12 months if the company decides to part ways with the communities.
It's hassle to maintain LPGL version with 12 month lag for sure.
What if they decide to put all the docs behind a paywall? And if they can't because of licensing reasons, what if they just stop paying people to update the docs and make a new version of the docs without licensing restrictions?
There are a lot of ways this can get worse.
Licensing protection isn't a silver bullet. If the organization becomes hostile, it only guarantees you the ability to fork. While that's huge, it's of limited utility if the project is too big to fork. See Chromium. I think Qt may be too big to fork.
Qt is effin' huge, but it is also at the core of a big and diverse ecosystem. There are many, many users across various industries, including big players and there are companies that offer consulting and development services specifically around Qt. If the Qt Company was to piss enough of these users off, they could easily join forces to create an economically feasible fork. The real trick would be avoiding competing forks, I think.
[1] https://kde.org/community/whatiskde/kdefreeqtfoundation/
[0] https://support.mozilla.org/en-US/kb/firefox-reader-view-clu...
<style type="text/css">
pre {
white-space: pre-wrap; /* css-2.1, curent FF, Opera, Safari */
}
</style>
Edit: Ah, the problem appears to be that a Content-Security-Policy blocks it.
> Content Security Policy: The page’s settings blocked the loading of a resource at inline (“default-src”).
I wish there were screenshots of the UI. I did lot of customization of many UI componentents like slider, ListView and much much more.
Thanks for sharing the press releases!
Maybe something that uses modern C++ all the way. Such as the serenityOS UI library?
1. Just because something is open source, doesn't mean you cannot get support for it. There are plenty of companies that offer support for open source software, and yes, this costs money. But the general rule of thumb is that $1 of open source support replaces $10 of proprietary revenue.
2. All software has licenses, even from proprietary vendors. But proprietary licenses have no standards, each and every one should be reviewed before acceptance. And they can also change at the drop of a hat and _you have no recourse_. Having a standard set of licenses, and a community that could support a fork are both value unique to open source.
3. Reviewing compliance is a thing with or without actually using open source software. Even if you say "we don't use open source software", that doesn't actually stop anyone from doing some copy-posta of code from some website.
1. You can get support sometimes - the question is at what price and at what quality and at what timeliness. Open source is no cure here.
A quick test: I googled "support for scipy" and found zero places I can buy fixes or support in the many pages I clicked through. I googled "support for Mathematica" and top hit (and the entire first page) were all support.
Try the same thing for any open source project, and the comparable commercial product, and tell me which seems to have more support available.
>general rule of thumb is that $1 of open source support replaces $10 of proprietary revenue.
That "rule of thumb" doesn't show up in a google search except for your comment. I'm not even sure what it's supposed to mean. Clarify?
2. "But proprietary licenses have no standards": every single proprietary license I've bought or been on the group deciding what to license has been nearly trivial - usually you buy an outright license to use as you will (and no open source gotchas to worry about what code touches what), or has been some tiered revenue/sales thing, all trivial to navigate. They are much easier than all but an open source "use for anything at will" license. And they don't trigger a host of legal issues. And there are dozens of open source licenses in common use, each with a host of legal issues to work out. This is why legal depts on every project I've needed to integrate must oversee each item we want to integrate, but not on buying licenses from proprietary vendors.
3. Proprietary code is backed by a vendor you can sue when you get sued, especially if they claimed compliance they did not meet. This provides legal protection when using their products. Open source has none of this, so all risk is on you, and you have to price this in.
All these factors have costs to development, risks to legal. Try integrating some open source into pacemaker code and see how much trouble and cost that is from legal, compared to buying proprietary, certified, components. Or car software (not dash entertainment, but driving critical stuff). Or infrastructure code like power line stuff, safety stuff, etc.
I like open source, and use it for lots of playing around, and where applicable. But it's a nightmare for a significant amount of work outside the HN popular web apps and social media startups. Most software development is not in these spaces.
Basically what they are saying is that "there is more to look than just sticker price. It's not just because the software is open source that TCO is lower."
I hate pipermail with a passion, it's 2022 and still it's a hassle to read mailing list posts...
https://lists.qt-project.org/pipermail/development/2022-May/...
Can we please get a better UI for mailing lists? The text is too small for me to comfortably read, so I used Chrome's zoom feature. But once I zoom in, the text wrapping is completely static so I'm forced to scroll horizontally.
Is there a more accessible way to read content on mailing lists?
Nokia bought Qt in 2008 for $150M. (The original name of the company was Trolltech.)
Sold it in 2012 for only $5M.
Ten years later, Qt Group is worth about $2 billion today, having reached as high as $5 billion last year.
How do you first lose 97% of the value of an asset, then watch on the sidelines as it goes up 1000x? Nokia's management was both incompetent and incomprehensibly negligent in handling shareholder value when they let this asset go for 5 million. Of course these managers were selling Qt for almost-nothing to their good friends in Finland, while the bill was paid by Nokia's global shareholders... This kind of borderline theft is easier to pull off in a small country, even one that pretends to be the least corrupt in the world.
To me the message didn't sound like a manifest but more like an info (to make the change smooth)?
Therefore I guess that people that know QT just don't care about speculating about that (why now/before/later, who cares) - of course this info will be remembered if in the future problems arise.
I liked the dual-license approach, but apparently it's not as "pure" as I thought was?
So he is mostly likely well-off already, and has friends doing interesting stuff. No need to continue working at a boring job.
QT and Qt Creator is more evolved than both (I don't know recent Delphi versions, but still think so). In Delphi (not sure about VB) you can do Text1.Caption := "Hello World". In QT Creator (last time I tried), you have to create some code to connect the signals to slots and still call a method to achieve the same thing. It was a bit more work but, easy, clear intuitive, well documented and has advantages when implementing more advanced features in a more generic way. I'd choose QT over both others today even for beginners and even disregarding licenses.
Lazarus beats Qt hands down in terms of efficiency and ease of use. I've found myself multiple times working with a Qt codebase thinking how much time i am wasting doing things by hand in an annoying way that could be done automatically by Lazarus. Qt's GUI designer is barely there and even something like wxFormBuilder for wxWidgets (another tool and toolkit i used at the past for similar types of applications) was better. Lazarus is much better on that front too with multiple approaches to lay out controls, both manually and automatically (and the approach in both frameworks show how one -Qt- was designed with a code-first approach and the other -Lazarus/LCL- with a WYSIWYG-first approach), though the anchor editor in Lazarus is kinda awkward (IMO it could be done in-designer instead of using a separate window). Things like designing reusable compound widgets are a code-free drag-and-drop manner in Lazarus (can even make per-instance modifications).
Note that all above are about Qt Widgets applications, i never used QML/QtQuick/etc (not my choice, but then again i'd also stick with Qt Widgets myself if i had to use Qt). Also the sort of applications i refer to are game engine tools since that is basically what i do.
Qt is better documented and much more polished though. Also Lazarus has a lot of "papercut" microissues that by themselves aren't that big of a problem but as a whole can give a bad impression. Finally Qt is better out of the box when it comes to being cross platform - Lazarus' native macOS support still has issues and some applications prefer to use the Qt backend (which also receives development from Linux developers) instead of the Cocoa backend for macOS.
QtCreator is neat but i haven't used it much. I found it a bit more awkward than Lazarus when i tried it out of curiosity (a friend insisted that it was the same as C++ Builder - no, it wasn't), but i think it is better than using Qt from anything else if for no other reason than having the IDE and designer "know" about the underlying framework (or at least i hope it does). I do not think you can do stuff like edit non-visual objects in it though and i'm not sure how you'd add new widgets in the designer.
It was certainly part of what made me hate programming and then wake up out of my stupor to find Go and learn to love programming again.
Bye bye Qt and C++, never going to touch you again if I can possibly help it.
C++'s std::string is Qt's QByteArray though, not QString which represents an actual Unicode string.
His influence is monumental.
In the Wikipedia entry on The QT Company, he is (still) mentioned as the current CTO.
200 lines of how wonderful the company was and all the great people and all the great accomplishments and yadda yadda... and one cryptic line about why he's actually quitting.
And the "I want to try something new" line is always a cover for something else.
To me, leaving completely signals something else.