Qt Blog
blog.qt.io · Company blog · on HN since 2015
The Qt Blog is the official blog of the Qt cross-platform UI framework, covering releases, roadmaps, WebAssembly and Python bindings.
What HN saysCommenters cite it for roadmap details, such as QWidgets staying supported and Qt WebEngine's possible separate release cycle.
117HN people shared it
50linked it in comments
157stories submitted
4.8Kstory points
7 years agolast shared
2015people per year2026
Most-shared posts
- 1Native look and feel (for Qt)9 people · 1 points · first shared 2017 · discussion on HN
- 2Qt for WebAssembly5 people · 272 points · first shared 2018 · 207 comments on HN
- 3Qt for native client and emscripten5 people · first shared 2015
- 4Qt WebGL Streaming4 people · 58 points · first shared 2017 · 46 comments on HN
- 5Qt for Python is coming to a computer near you4 people · 54 points · first shared 2018 · 13 comments on HN
- 6Qt Roadmap for 20184 people · 4 points · first shared 2018 · discussion on HN
- 7Hello Qt for Python3 people · 318 points · first shared 2018 · 171 comments on HN
- 8Qt Creator 4.6 Beta Released3 people · 127 points · first shared 2018 · 87 comments on HN
- 9Qt Quick WebGL Streaming3 people · 105 points · first shared 2017 · 47 comments on HN
- 10Deprecation of Qbs3 people · 10 points · first shared 2018 · discussion on HN
- 11Qt Roadmap for 20193 people · 5 points · first shared 2019 · discussion on HN
- 12Qt Creator 4.1.0 released3 people · 5 points · first shared 2016 · discussion on HN
- 13Slate: A Basic Pixel Art Editor Built with Qt Quick3 people · 4 points · first shared 2018 · discussion on HN
- 14Qt quick controls re engineered status update3 people · first shared 2016
- 15Qt for WebAssembly Technology Preview2 people · 243 points · first shared 2018 · 191 comments on HN
What HN people wrote when they linked it
Longhanks · 2019-03-03
According to the 2019 roadmap, QWidgets is very much not dead and will get new widgets this year: https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/
My personal opinion of QML is also contradictional: QML on the desktop to me just feels like a glorified Electron, resizing windows is choppy, controls feel slightly "off", the "single page" approach just feels like it misses the platform's defining features (dialogs and multiple windows). Best example is KDE Discover. But I'd like to be proven wrong, I'd love to hear of QML desktop software that is genuinely high quality, but I haven't heard of any.
ahartmetz · 2019-01-09
Well, you are looking at the description of the software renderer.
Qt Quick is hardware accelerated (OpenGL) by default. A subset of it is supported by the software renderer. With hardware acceleration, performance is generally great.
Actual rendering overview (rather technical):
http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html
Cool blog post about performance improvement through draw call batching: http://blog.qt.io/blog/2013/09/02/new-scene-graph-renderer/
jcelerier · 2018-09-26
the app looks beautiful, they put Qt widgets to their best looks. I wonder if the idea was inspired by the demo pixel art program : http://blog.qt.io/blog/2018/03/06/slate-basic-pixel-art-editor-built-q…
rjzzleep · 2018-09-26
Considering that 5.12 is an LTS release, they are evaluating to separate WebEngine from the normal QT release cycle.
> This is still under research, but there seem to be quite tangible benefits from carving out Qt WebEngine to a separate item. Current thinking it that as a separate item we should be able to release Qt WebEngine every three months, following nicely the schedule of Chromium releases every six weeks. For Qt 5.12 LTS users this would mean the possibility to get not only the security updates, but a full new Chromium version supported on top of the long-term-supported release of Qt.
https://blog.qt.io/blog/2018/02/22/qt-roadmap-2018/
oever · 2018-05-18
By default Qt renders with OpenGL. You can talk to OpenGL via the Qt APIs. You can provide application logic in Rust, but the actual GUI is still written en C++ or QML.
You can use Qt 3D for a UI with Rust logic. Writing a 3d scene with the declarative QML language is nice. Or you do this with your favorite text editor or Qt 3D Studio.
http://blog.qt.io/blog/category/qt-3d/
pjmlp · 2017-12-19
Too late, WebAssembly is already here.
I really think it will bring Flash like web sites back, and browser vendors are the ones actually pushing it.
The wheels are already in motion, with everyone trying to port their favorite language or VM into WebAssembly.
For example, today it is Qt WebGL Streaming, tomorrow it might just run directly from WebAssembly.
http://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged/
It will be up to those frameworks to provide usability support, like WPF does for Windows.
barrkel · 2015-12-20
Most C and C++ programmers' mental models of the machine is different to the abstract machine in the respective specifications. [1] There's a genuine problem here of overly clever optimizers wilfully misreading code to produce fast, wrong code. But the compiler exists to map our ideas into code; it's a tool to help us, not catch us out in a lawyerly fashion.
I will say that the article isn't a fantastic example, but at the same time it isn't too far off a more common idiom that is also UB as it is usually expressed - type punning. And type punning almost always works, except when it doesn't - http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-aliasing/
[1] In particular, most programmers think pointers are simply numbers that represent memory addresses and that the chief distinguishing thing about null pointers is that accesses through them usually cause a memory page error owing to how the OS has mapped memory.
Memosyne · 2019-01-17
> they are just mostly finished
Yeah, I don't know how much experience you have with Qt but widgets are far from being "finished". There's plenty of things that could be improved if their focus wasn't on Qt Quick.
The use of Qt Widgets is declining (albeit slowly), as stated in http://blog.qt.io/blog/2019/01/14/qt-customer-survey-2018/. You're telling me that they're going to support two different technologies that do the same thing without giving preference to the newer, technically superior one?
Qt Quick is intended to replace Qt Widgets, but it isn't currently at a stage where that's feasible -- hence my apprehension.
eliaspro · 2019-01-17
Yes, it does: http://blog.qt.io/blog/2018/05/22/qt-for-webassembly/
AlexFagrell · 2019-01-08
Agree, unfortunately the Qt company decided to "deprecate" it, or rather to not put anymore resources into it:
http://blog.qt.io/blog/2018/10/29/deprecation-of-qbs/
empyrical · 2018-12-13
I am not sure how this is going (this blog post is the only info I can find on it) but they have plans to make a new UI library for Qt that is backed by the platform's native widgets, like AppKit on macOS:
http://blog.qt.io/blog/2017/02/06/native-look-feel/
Const-me · 2018-12-02
Technically, LGPL option allows using in proprietary software. Practically, static linking is often better e.g. makes executable much smaller. And even with dynamic linking, see this note from https://blog.qt.io/blog/2009/11/30/qt-making-the-right-licensing-decis…
> If you are shipping an executable, you must include any data and utility programs needed for reproducing the executable (i.e. must provide components needed to recompile with a new version of the library) unless such data and utility programs are normally distributed with the major components of the operating system on which the executable runs
For developers of proprietary software, flutter’s BSD 3 clause license is way easier to comply.
int_19h · 2018-11-19
Then we need APIs that would allow GUI frameworks that render onto <canvas> to support accessibility. Such APIs have existed on desktop platforms for decades now, and popular frameworks like Qt use them, even when they draw all the widgets themselves.
By the way, Qt-on-wasm-on-canvas is already a thing:
http://blog.qt.io/blog/2018/05/22/qt-for-webassembly/
mherrmann · 2018-11-16
I've been developing a cross-platform file manager [1] for the past 2.5 years. It is shareware with a nag screen. It currently makes ~$500 per month. Generally, I would say yes, shareware still works. But it is hard a) to write desktop software [2] and b) to convince people to pay for it. I would not give people the sources. It would make them feel even more like "I don't need to pay for this". What works for me is to be very transparent and tell people [3] "I'm one guy working on this, and am making $500 per month. This is not sustainable. If you like the project and want it to continue, buy a license".
Feel free to hit me up on twitter @m_herrmann if you have further questions. :-)
1: https://fman.io
2: https://blog.qt.io/blog/2018/11/15/python-qt-3000-hours-developer-insi…
3: https://fman.io/buy
tlamponi · 2018-09-26
I run Linux without desktop environment on a 4K screen, so I ran into this stuff on all GUI kits.
I set the respective scale detection/factor variable in my environment and be done, e.g., for QT5 it'd be:
export QT_AUTO_SCREEN_SCALE_FACTOR=1
for auto scaling. See: https://blog.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6/
and https://wiki.archlinux.org/index.php/HiDPI#Qt_5 for more options and other UI kits.
Normally, the desktop environment should do this for you, though. But yeah, this was quite horrible for me for a long time and only got better recently (~ 1 to 2 years), with an wider adoption of high DPI screens, I'd guess.
electricslpnsld · 2018-08-07
I don't think there is any Rust (or any Rust on the roadmap) in Blender -- they would most likely use MoltenVK on macOS, similar to the path the Qt folks are taking [0].
[0] http://blog.qt.io/blog/2018/05/30/vulkan-for-qt-on-macos/
remoroid · 2018-07-20
Ouch. Mac for Qt is definitely the weakest point. Theres some experimental work being done to allow developers to wrap native Mac controls. http://blog.qt.io/blog/2017/02/06/native-look-feel/
elcritch · 2018-06-07
True! Statecharts are handy in lots of domains. Embedded happens to be a prime target due to the memory constraints combined with often limited behavioral requirements.
IMHO, most websites / UI's implement half of a poorly understood state machine (to roughly paraphrase the Common Lisp quip). Qt apparently also has an interesting statechart engine as well: http://blog.qt.io/blog/2017/01/23/qt-scxml-state-chart-support-qt-crea…
freedomben · 2018-06-01
The article links to http://blog.qt.io/blog/category/functionalsafety/ which has a lot more details.
The short answer tho, is that "the tooling separates out the safety-critical elements for execution by the Qt Quick Renderer run-time."
AsyncAwait · 2018-05-19
52-6F-62 · 2018-05-19
You bet! Maybe not web-like, but:
https://www.wxpython.org/
https://blog.qt.io/blog/2018/05/04/hello-qt-for-python/
I have very little experience with both outside of tinkering, but they will probably be gratifying and practical enough to build something that works to encourage him further.
msie · 2018-05-05
http://blog.qt.io/blog/2018/04/13/qt-for-python-is-coming-to-a-compute…
"PySide2 – the bindings from Python to Qt – changes skin this spring. We have re-branded it as Qt for Python on a solution level, as we wanted the name to reflect the use of Qt in Python applications. Under the hood it is still PySide2 – just better."
WaltPurvis · 2018-05-03
Less mature for the moment, but it's getting more official support and resources, so that will probably change. (They've also changed the name from PySide2 to Qt for Python.)
http://blog.qt.io/blog/2018/04/13/qt-for-python-is-coming-to-a-compute…
License-wise: "Qt for Python will have the same licensing as Qt for Application Development, i.e. it will be available under GPL, LGPL and commercial."
mappu · 2018-04-23
Note that Qt has two separate technology previews for porting Qt apps to run in the web browser:
Qt WebGL streaming (qplatform/qpa plugin):
The Qt binary runs on your PC as normal, but instead of opening an X11/Win32 window, opens a network port. You can open the URL in a browser to see the interface. Only one connection is allowed / only one user can interact with the app at a time.
Technology preview since 5.10, will be "TP2" status in 5.11. See http://blog.qt.io/blog/2017/11/14/qt-webgl-cinematic-experience/ and http://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged/
Qt for WebAssembly:
The entire QtWidgets / QML libraries are compiled to WASM and run clientside. There is no server-side component.
Will be released as a technology preview in the upcoming 5.11 release.
lultimouomo · 2018-02-08
You can get more info directly from the source:
http://blog.qt.io/blog/2018/02/07/qt-creator-4-6-beta-released/
Aissen · 2018-02-01
It started moving from LGPLv2.1 to LGPLv3 in Qt 5.4 with new features, and is now the norm since Qt 5.7 (latest in 5.10):
http://blog.qt.io/blog/2014/08/20/adding-lgpl-v3-to-qt/
https://www1.qt.io/faq/#_Toc_1_2
clouddrover · 2018-01-02
Qt can work in the browser. Here's a Qt blog post talking about their Emscripten support: https://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-emscripten…
You can also stream Qt applications via WebGL (runs server side, UI streamed to the browser): https://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged/
Some asm.js Qt examples: http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/…
Some WebAssembly Qt examples: https://github.com/msorvig/qt-webassembly-examples
martin_ky · 2017-07-31
Yes, I (post author) believe QML can be implemented on top of current browser tech, namely JS+DOM, or NaCl+WebGL. Someone indeed did implement a subset this way - https://qmlweb.github.io/ and the latter might even be supported by Qt Company - http://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-emscripten/ although I didn't try that myself and I don't know if that effort is still ongoing.
I'm not a fan of stacking too many abstractions on top of each other. QML basically consists of the same ingredients as other web tech: a javascript runtime + GL/ES renderer + network access manager = same things a HTML5 engine needs under the hood. Surely these could be reused in a browser implementing QML.
DocSavage · 2017-07-07
From an earlier discussion of it:
"The OpenGL calls are sent over the network and transformed into WebGL calls in the browser. It’s not video-streaming. The browser is executing WebGL in a canvas. Textures, buffers, glyphs, etc. are sent as well.
You need a browser with WebGL support. Tested on IE11, Firefox, Chrome, Edge, Chromium."
http://blog.qt.io/blog/2017/02/22/qt-quick-webgl-streaming/
I assume only a subset of OpenGL calls can be sent and things like 3d volume textures would eventually require WebGL2?
moron4hire · 2017-07-07
> Some time ago I published a couple of blog posts talking about Qt WebGL Streaming plugin
I had to search to find out for sure what he was talking about. A Qt application runs a small, local web server, streaming UI calls to a WebGL context on a page you view through your browser of choice. http://blog.qt.io/blog/2017/02/22/qt-quick-webgl-streaming/
This differs from Electron in that your backend is C instead of JS, your UI is Qt instead of HTML, and the runtime doesn't embed the browser. I'm just guessing, but I suspect you also don't develop any code on the browser client context.
I've also personally found value in running Electron from a page in a local HTTP server process, so I don't find that part too different, but YMMV.
Maybe it's more appropriate to say this is like per-app RDP via WebGL.