Qt is an amazing piece of tech that got many things right.
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 :)
QML is Qts innovation. The declarative way to write a UI is unmatched IMHO when comparing to Unreal, Godot or the Web. Still, QML has a _lot_ of other little problems like bad tooling (no autoreload, unusable designer) and often broken type system where you can assign invalid properties, and it will silently fail.
QML on the desktop is highly buggy. The menu bar doesn't close when you click on other windows (even after 10 years), it took a decade to create a half-decent Qt Quick Controls 2 file dialog, there were multiple tab order bugs where pressing Tab hung the app (in Qt Widgets it would instead highlight the wrong widget when you pressed Tab then Shift-Tab) and one of them was fixed after several years mere weeks ago (https://bugreports.qt.io/browse/QTBUG-87190), mouse scrolling (Flickable) works differently from Widgets (and scrolling twice quickly can travel 4 times the distance as scrolling once), on Android it drops frames even on a fairly high-end phone (Pixel 4a) and interactions feels uncanny-valley... I'm under the impression that you're almost not meant to use Qt Quick Controls 2, since KDE created their own Item hierarchy, rejecting Qt's own Flickable altogether.
KDE still uses QQC2 and Flickable. However, we do workaround Flickable's deficiencies by filtering mouse wheel input on QQC2 ScrollViews and setting the content X/Y values so that it moves more like a view in Qt Widgets. It's not ideal. I hope one day I or someone else will be able to fix Flickable's behavior upstream.
Autoreload can be added quite easily, like in this Lisp binding, which has an example where even single file autoreload works, both on desktop and mobile, simultaneously:
It's also not truly declarative since you can observe ordering (and therefore your app may silently depend on imperative execution)
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)
> 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.
-Like React/React-native ecosystem pioneered the component based declarations of UI elements.
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.
There's a common misconception that JSX is XML - that's very excusable as the syntax is based on XML, but it's not the case and you should look into JSX in more depth if you think it is.
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 think the point was that they were declarative and retained mode systems and existed long before react. I'm deeply familiar with React and systems such as WPF/QT and I can see the comparison.
> I think the point was that they were declarative ...
> 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.
I have to disagree. You produce a data structure representing the UI. That's basically the definition of declarative. Just because you can build that dynamically doesn't mean it is not declarative. You could always build up XML dynamically as well.
It's a far cry from an immediate mode API where you are making draw calls.
A React component is a class or function - there is no static "data structure", except for what any individual dev might define as convention for their own application. Unless we're calling class members "declarative data structure", in which case we may need to revisit some definitions across the programming world.
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 know what React and JSX were 6 years ago, I understand now it much more complex, I even done React components without JSX and use the React.Div functions to render components.
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.
Another fun fact about React (at least React Native): there are basically two separate "engines" for class-based and function-based components, with subtle differences.
I think you are confusing XML style UI declarations with composable-components-based UI declarations.
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)
> 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:
you think bindings are super cool like bind the hidden state of soemthing to some variable then Flex did it before React and probably was not the first.
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.
What's sorely needed is an open state-ful GUI markup language that targets CRUD and data, something HTML/DOM still sucks bigly at. We wouldn't need language binding libraries if we could issue XML to give us all the common and loved GUI idioms like tabs, drop-down menus, data grids, pop-up windows, tool-bars, combo-boxes, etc. (That HTML5 deprecated frames and iframes is a shame. Anti-Kudos to the 5'ers. Fire those b@stards!)
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?)
Qt has data grids built in, but QAbstractItemModel is a nightmare to implement and interface with (https://www.reddit.com/r/QtFramework/comments/rx0c8e//hrfvyz..., https://docs.google.com/document/d/1__bldg9SwENN2d6LyiX0wwX5...). I think some of the incidental complexity could be fixed, and the implementation could definitely be simplified by removing dragging between widgets (which requires the model's backing data store be built around adding and removing items, rather than merely reordering them), but I feel it's inherently difficult to communicate changes to data to the QAbstractItemView in the form of individual insert/delete/move operations. I haven't explored the JS world's approaches to UI diffing or lazy-loaded data grids though.
I have no idea why browsers maker don't look at what Desktop and Mobile GUI frameworks provide and implement same functionality, like give us a ListView or GridView that is implemented to be efficient and you don't have to use pagination as a workaround.
I'd add treating the KDE community with contempt to the negative side of your list. KDE did a lot to breathe life into Qt and that seems to have been forgotten.
There were rumors that Qt wanted to take the project proprietary. They didn't go through with those plans, but right now they are delaying all patch releases of Qt5 by 12 months, forcing KDE to maintain their own set of backported patches )https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15), and rebase on top of Qt 5.15.3 and .4 etc. every so often, until KDE eventually ports to Qt 6.
What do you mean by "component based declarations of UI elements"? Declarative specification of UI widgets (e.g. XUL) is much older than web-based component frameworks like React. Component orientation in UI frameworks is even more traditional, and far older than Qt.
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.
Single code base for multiple platforms is not impressive these days, you can do it in many frameworks. The key thing seems to be 1. written in C++ (hence performant) and 2. Has a declarative language (QML).
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.
>Not limited with a single language (has bindings to all major languages)
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.
>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".
Licensing has gotten much worse, so much so that my current firm is sticking with our Qt5 contract and will not negotiate to Qt6. So we're hitting the end of the road with Qt in the next few years.
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.
This is my experience as well. Core bugs keep pilling up for years at an alarming rate while they focus on adding new functionality that most developers don’t need.
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.
> Qt is much faster than other UI technologies, but it’s far from being as performant as native solutions are.
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'm not seeing why the DOM would necessarily makes rendering slower.
See e.g. this comparison showing react web being faster and more energy efficient than react-native.
https://ionicframework.com/blog/ionic-vs-react-native-perfor...
It's true that pathological DOM dynamism might incur some cache/layout invalidations, however if that were to be an issue (which is very rare and profiling is easy), you could mostly eliminate the problem with a few lines of https://developer.mozilla.org/en-US/docs/Web/CSS/contain
QML and QtQuick are actually declarative and reactive in ways that React isn't, and I find them much more pleasant to use than React, especially when it comes to separation of concerns. They've existed for quite some time, too.
QT has retreated to what is the absolute minimum it has legally to do. They can't pull away any more. QT and KDE have legally binding agreement.
>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.
I'm more concerned about the show of intent than the specific actions up to this point.
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.
The Qt Company itself isn't bound by licenses on the code/documentation, but by a separate contract with the KDE Free Qt Foundation [1]. This document is publicly available and treats the documentation pretty much equal to the code itself.
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.
Somewhat unrelated: When I open the link, the lines of text are super long and do not wrap in a standard desktop browser. Am I doing something wrong? Or: Is there a trick to force wrap the text in a browser?
Perhaps it's to make sure code snippets are correctly aligned, but a link to a wrapping version would be very useful, or perhaps just letting very long lines wrap in a narrow browser window, because the current model means that you have to scroll horizontally as you read every single line, even on a very wide screen.
I learned this amazing C++ based GUI framework called "QT" (cute :)) in 2003. At that time it was owned by Trolltech. I developed UI for a Digital Cinema system which was used to project movies in theaters. Amazing framework to work with and lots of good doc for developers.
Screenshots would have been fun to see - I'm always fascinated by projects like these that are part of an industry-wide transition to something new. Especially considering you probably didn't have much or any prior works to guide what you built.
What is an abomination? It lines up well with my experience using both Qt and open source and also using both in projects. Certainly issues 2,3,4 cause problems for any project wanting to integrate open source into commercial work. And 1 seems on par with experience. For all points they cite decent sources.
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.
It's (unsurprisingly) extremely biased towards "buy from us", presenting only upsides of commercial licensing and downplaying them on the open-source side. The comments are good starting point for why their representation of what you get when you buy are ... optimistic.
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."
It's not and it's not a blog that is hostile to open source like it's being pawned as. It's just saying there is a cost/tradeoffs just like any other way of doing software. Some OSS advocates won't hear any of that. They just hear insults to their favorite project.
Except that, back in the day, a much touted advantage of GTK+ was its LGPL licensing, making it more suitable for writing proprietary software. That was basically Red Hat speaking, which has always been the strongest backer of GTK+ and Gnome.
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?
It's an amazing example of how Nokia mismanaged their assets and sold them away for a song.
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.
Just went over the comments and am once again amazed that none of the comments goes into the referenced message; most people discuss something else, or ask questions that are answered in the referenced message; but hardly anyone seems to care that the most important technical head of the company is leaving, or why just now (that he is leaving at this time seems rather coincidental according to the text, and why leaving a well paid, secure position for a startup, at his age?).
> anyone seems to care that the most important technical head of the company is leaving
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.
There has been quite a bit of controversy over the direction of Qt. I've been working with Qt for more than twenty years and find the news pretty amazing, as no doubt do many others. With Qt 6, the company has entered similar waters as the developers of Wayland: building something with a lot of effort, that is functionally only marginally different from the established technology, but significantly less mature.
Qt4 is/was much better than Qt3; and Nokia made it available to everyone under LGPL which was sensational; Qt5 mostly improved modularity and platform abstraction; after the Nokia aera, Qt has given itself a bit of an orientation log, adding features in all sorts of directions that didn't necessarily add to the core proposition, but increased complexity and development effort, without adequate value in my view.
If you don't understand the problem, you probably belong to a younger generation. In older years, you change jobs only when it's unavoidable. In informatics, it is already very difficult to find a job from the age of 45. So there must be important reasons. If he simply wanted to retire, he would hardly have mentioned the startup.
While that affects most older workers, one group that it doesn't are famous, well-connected, high-achieving folks. It's not like Guido van Rossum is hurting for work, for example.
So he is mostly likely well-off already, and has friends doing interesting stuff. No need to continue working at a boring job.
One question for GUI folks. Comparing to the classic RAD tools such as VB and Delphi, does QT match the efficiency and easy-to-use? Appreciate any insight.
I had just superficial experience with each of these tools, which I think is more adequate to answer your question since VB and Delphi are very productive for people who have little experience.
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.
I used both Embarcadero Delphi and Qt extensively, and I prefer Qt due to their nice IDE integration with lots of other tools, like valgrind, clangd, gdb, etc., and simply a faster, snappier experience. And its unapologetically cross platform.
VB and early Delphi (say Delphi 7 and earlier) have their pros and cons compared to current(ish) Qt. I don't know about modern Delphi but i do know about modern Lazarus (which is basically an open source Delphi) and have worked in similar complex desktop applications in both.
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.
I worked on a project using Qt for several years. It was okish, certainly a useful cross platform addition to C++ code. But it was so big and so opinionated... I mean come on: C++ has strings, what business do you have adding your own magical strings?
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.
The main guy behind QT, while not the first on the project, he has been the main vision behind all the technical parts for 25 years. He wrote the engine that we now know as webkit and chrome.
Considering what happened to khtml in the last 15 years I'd use firefox myself. Come to think of it I actually did get one patch into khtml back in the day (exactly one, don't read too much into this), and I now use firefox. I keep thinking I should resurrect the khtml project so we get a good open source engine again - (firefox is more than an engine), but realistically it needs more love than once part time person can give it.
"Lars Knoll is The Qt Company CTO and Qt Project Chief Maintainer. He has been working on Qt for more than 13 years starting as a software engineer to later leading the global Qt engineering team in Nokia before the Digia acquisition in October 2012."
It probably means: "more than 13 years BEFORE the 2012 accusation". Because I already knew Lars Knoll as involved with QT back in 2000 (except if he was just working on the KDE side then).
I remember the kerfuffle about QT licensing and KDE. Back then I used KDE and dismissed the concerns. It’s been odd and unfortunate to see those concerns having been at least partially founded.
I hate these emails, and LinkedIn is guilty of this too.
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.
Lars wrote Webkit in the middle of Qt development. Surely he could find out-of-band time and headspace to tinker with different technologies if he wanted to.
Your choice of words did not go unnoticed. You could say Lars is a bit of an expert on signals... he's off to some unknown slot, connected by destiny! ;)
Isn't it possible that he's tired of c++ and Qt after 25 years? I mean he's starting a new startup so he probably can't reveal what that is, but it's obviously something he's excited about. Hell after 2 or 3 years at company I'm ready to finish up whatever I'm working and move on to somewhere else.
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 :)