Qt Archive
Volker Hilsheimer, chief maintainer of the Qt project, says he has learned lessons from the painful Qt 5 to Qt 6 transition, the importance of Qt Bridges for using Qt from any language, and the significance of the relationship with the Linux KDE desktop. ↫ Tim Anderson at Dev Class Qt plays a significant role in the open source desktop world in particular, because it’s the framework KDE uses. Hilsheimer notes that KDE’s role in the Qt community is actually quite important, because not only is it a source of people learning how to use Qt and who can thus make contributions to the project, KDE also tends to use the latest Qt versions, creating a lot of confidence among the wider Qt community to also adopt the latest versions. The relationship with KDE and Qt is an interesting one, and sometimes leads to questions about the future availability of the open source edition of Qt since the Qt Company licenses Qt under a dual-license structure (both open and proprietary). To avoid any uncertainty, KDE and Qt have an agreement that covers pretty much every possible scenario and which is worded to ensure the availability of Qt as an open source framework. KDE, through the KDE Free Qt Foundation, has a number rights and options to ensure the availability of Qt as an open source framework. I’m no lawyer, so I might get some of the details wrong, but the main points are that if the Qt Company ever decides to discontinue the open source edition of Qt, the KDE Free Qt Foundation has the right to release Qt under a BSD-style license within 12 months. The same applies to any addition to Qt which are not released as open source; they must be released under an open source license within 12 months of initial release. This agreement remains valid in the case of buyouts, mergers, or bankruptcies. This agreement has existed in one form or another since the late ’90s, and has survived Qt being owned by Nokia and Digia, as well as various other organisational changes. Despite the issue of Qt’s ownership coming up every now and then, the agreement is pretty airtight, and considering its longevity there’s no reason to be worried about it at all. Still, this structure is clearly more complex and less straightforward than, say, the status of GTK and its relationship to GNOME, so it’s not entirely unreasonable the issue comes up every now and then. I wonder if we’ll ever see this situation become less complex, without the need for special agreements. While it wouldn’t make a practical difference, it would make things less… Legalese.
Earlier this week, Qt 6.7 was released with a whole slew of new features and improvements. Reading through the various highlights, there’s further improvements to Qt Graphs, first released with Qt 6.6 and still under active development, better SVG support, variable fonts and icon font support, and much more. There’s also a variety of new examples and demo applications, and of course, Qt 6.7 supports all the latest operating system releases. One feature that truly stood out to me as something that I’m assuming will make Qt developers happy is improved support for embedding native controls into Qt applications. On both desktop and mobile platforms, applications often need to combine UI elements from different technologies and frameworks. Qt uses and integrates tightly with the native technologies on each platform to create basic UI elements such as windows, and it has for a long time been possible to use UI elements from other frameworks within a Qt Widgets application. With Qt 6.7, we are now adding support for embedding native windows into a Qt Quick scene as well. This allows use of native controls such as AppKit’s MapView or a Windows media player inside a Qt Quick UI, with correct positioning and stacking. By layering windows, Qt Quick UI elements can be overlaid on top of the native components as well. ↫ Volker Hilsheimer Alongside Qt 6.7, Qt Creator 13 has also been released, which comes with its own set of improvements and new features.
Today marks the 6th time we are releasing new functionality in the Qt 6 series, with small and large additions that make both UI and backend development more productive and fun. Several of the new features come as technology previews, and we are looking forward to your feedback so that we can get everything in tip-top shape for the next LTS release! Lots of new goodies for Qt developers.
Every release has a killer feature. Qt 6.6 features the opposite – staying alive. This blog post describes work to make Qt clients more robust and seemlessly migrate between compositors, providing resistance against compositor crashes and more. Qt 6.6 is bringing something to the Linux desktop we haven’t had yet: transparent recovery from display server crashes. The solution for this? Instead of exiting when the compositor closes, simply…don’t! If we could connect to a new compositor we just need to send the right amount of information to bring it in sync and notify the application code of any changes to bring this in sync. For Qt applications all this information is handled in the backend, in the Wayland Qt Platform Abstraction (QPA). Qt already has to handle screens and input devices being removed, clipboards being revoked and drag and drops cancelled. Supporting a whole reset isn’t introducing any new work, we just have to trigger all of these actions at once, then reconnect to the newly restored compositor and restore our contents. Applications already have to support all of these events too as well as handle callbacks to redraw buffers. There’s no changes needed at an application code level, it’s all done as transparently as possible. The benefits here are legion: you can run two different compositors on two different monitors. You can switch compositors at runtime. You can add new features without logging out and back in. Checkpoint restore in userspace, and more. All this made possible by Wayland – X.org cannot do any of these things.
At the time the KDE Free Qt Foundation was founded, Qt was developed by Trolltech–the company that originally developed the framework. The Foundation has supported Qt through its transitions, first to Nokia, then to Digia, and finally to The Qt Company. It has the right to release Qt, if necessary to ensure that Qt remains open source. This remarkable legal guarantee protects the free software community and creates trust among developers, contributors, and customers. This special deal is well-known, but it’s also kind of unique. It’s great that KDE has such a solid guarantee in its back pocket in case of an emergency.
Key changes in Qt 6.0 include: • Leveraging C++17• Next generation QML• New graphics architecture• Unified 2D and 3D for Qt Quick• CMake build system (with qmake still supported for applications)• Multiple improvements throughout A big release – but I’m not a programmer so I won’t pretend to try and understand all of this.
With the release of Qt 6.0 upcoming, let’s see what has happened since Qt 5.15. It will not be possible to cover every detail of the graphics stack improvements for Qt Quick here, let alone dive into the vast amount of Qt Quick 3D features, many of which are new or improved in Qt 6.0. Rather, the aim is just to give an overview of what can be expected from the graphics stack perspective when Qt 6.0 ships later this year. Exactly what is says on the tin. Especially Qt developers will obviously want to read this.
As the last release of the Qt 5 series, we wanted to make sure that Qt 5.15 is a great release that you can easily upgrade to with your ongoing projects. It is, as always, fully backward-compatible with previous Qt 5 releases. A large amount of work has gone into bug fixes, and Qt 5.15 is the best and most stable release we’ve done in the Qt 5 series. Qt 6 is expected before the end of the year.
There’s a storm brewing in the world of Qt and KDE, as the parent company of Qt, The Qt Company, is contemplating restricting new Qt releases to paying customers (i.e., not releasing them as open source) for twelve months. This obviously affects the KDE project considerably, who have been negotiating with The Qt Company for years now. An announcement made by The Qt Company in January derailed said negotiations, however. As KDE’s Olaf Schmidt-Wischhöfer explains: They announced that LTS releases of Qt will only be available for paid license holders. It is still unclear what this implies for contributions to Qt and for the sharing of security fixes between the various parties (including The Qt Company, the many Qt experts contributing, the KDE community, and Linux distributions). It seemed the two parties were working on a path forward acceptable to all parties involved, but then came the announcement earlier today that The Qt Company was contemplating restricting all releases to paid customers for twelve months. It seems bad blood has been brewing for a while, as Schmidt-Wischhöfer states: The Qt Company says that they are willing to reconsider the approach only if we offer them concessions in other areas. I am reminded, however, of the situation half a year ago. We had discussed an approach for contract updates, which they suddenly threw away by restricting LTS releases of Qt instead. 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. We will continue to work on a contract update that helps all sides. But even if these negotiations were to be unilaterally stopped by The Qt Company, Qt will stay Open Source, and KDE will be able to use it. I am also absolutely sure that the Qt + KDE communities will continue cooperation on new features, bug fixes, and security fixes, even should The Qt Company decide to forgo the benefits of cooperation. Luckily for the future of KDE and Qt, there is an agreement in place between KDE and The Qt Company that states that “ should The Qt Company discontinue the development of the Qt Free Edition under the required licenses, then the Foundation has the right to release Qt under a BSD-style license or under other open source licenses.” This is a serious issue that I hope can be resolved, as nobody will benefit from a serious rift between The Qt Company and the KDE project.
Qt Marketplace is an innovation platform for our community. It brings together Qt developers and designers looking for new ways to enhance their Qt design and development workflow, and developers and companies who have already implemented extensions to Qt and want to make them available for everyone in the whole Qt ecosystem. Either for free or for a price. In the initial release our theme is discoverability. To put this simple: We want the marketplace to become the #1 place for our community to find and share content for Qt. An app store for Qt developers, basically.
7 years ago, Qt 5 was released. Since then, a lot of things have changed in the world around us, and it is now time to define a vision for a new major version. This blog post captures the most important points that can and should define Qt 6.
Qt Design Studio is a UI design and development environment that enables designers and developers to rapidly prototype and develop complex and scalable UIs.
Qt Design Studio is a tool used by both designers and developers and that makes collaboration between the two a lot simpler and more streamlined: Designers can look the graphical view, while developers can look at the QML code. With this workflow, designers can have their Photoshop designs running on real devices in minutes! As an aside, I say Photoshop designs, but we are planning to support other graphic design tools in the future.
Now that Qt 5.11 is released, it is finally time to upgrade the last Qt 1.0 applications out there... No, not really. I want to take a look at how well we have kept compatibility in Qt over the years since the first official release.
Qt guarantees source and binary compatibility between minor releases, and we take that seriously. Making sure that you don't have to rewrite (or even recompile) your application when you upgrade to a newer version of Qt is important to us. However, there are times when we need to make bigger changes in order to keep Qt up to date. This is done in major releases. Since the release of Qt 1.0 in 1996 (almost twenty-two years ago), we have broken source compatibility four times: in 2.0, 3.0, 4.0 (some of you may remember that as a painful transition), and 5.0.
We do try to keep breakages to a minimum, even in the major releases, but the changes do add up. This raises the question: How hard would it be to port a Qt application from Qt 1.0 to 5.11?
Not only an interesting look at Qt history, but also a look back on mid 90s C++, and what has and hasn't changed.
Great new things are coming with the latest Qt release. From image based styling of the Qt Quick Controls, new shape types in Qt Quick through to Vulkan enablers as well as additional languages and handwriting recognition in Virtual Keyboard. But wait, there is more. We fully support both OAuth1 & 2, text to speech and we also have a tech preview of the Qt WebGL Streaming Plugin.
The blog post about the release has more information.
I'm very happy to announce that Qt 5.7 is now available. It's been only 3 months since we released Qt 5.6, so one might expect a rather small release with Qt 5.7. But apart from the usual bug fixes and performance improvements, we have managed to add a whole bunch of new things to this release.
I'm happy to announce that Qt 5.6.0 has been released today! This release has taken a bit longer to finish than we originally expected, mostly because we put a lot of new infrastructure in place, allowing us to make Qt 5.6 a Long Term Supported (LTS) release. With that, Qt 5.6 (LTS) will be receiving patch releases with security updates and bug fixes for the next three years, in parallel to upcoming Qt versions.
Qt 5.1 has been
released. It brings several enhancements, Qt Quick Controls, Qt Sensors, a much better C++11, Wayland and OpenGL support, and the development of Android and iOS applications is very usable for a large number of use cases. In related news, the LXDE desktop
prepares the change to Qt.
"For
this preliminary release, we are focusing on the developer experience, working to enable Qt developers to easily run and test their applications on Android devices. While there's nothing preventing you from deploying your app to an app store with Qt 5.1, we're recommending that people wait until Qt 5.2 before they do that, as we'd like to put some more work into improving that experience: making more options for how your app is deployed, adding more polish in general, and adding more support for Android APIs, both by allowing you to extend your app with Java code or by mapping them in C++ APIs, whichever makes the most sense."
A Jolla (Sailfish) developer and a Canonical (Ubuntu Phone) developer walk into a KDE/Plasma IRC channel, and fire up a conversation about the QML component API. Not long after, the first fruits of this conversation become apparent. Aaron Seigo (who uses punctuation these days!): "Well, one thing led to another and Zoltan posted an
email to the Qt Components mailing list summing up the conversation and
proposing we bring our APIs into better alignment. We hope to address issues of API drift between the various component sets out there. This is a pain point others have identified, such as in this recent
blog post by Johan Thelin. There is much work to be done before we can even think of calling this a success, but it's the right sort of start." Great news.
Digia, Qt's new owner, has announced
the release of version 5 of the framework. "Key benefits of Qt 5 include: graphics quality; performance on constrained hardware; cross-platform portability; support for C++11; HTML5 support with QtWebKit 2; a vastly improved QML engine with new APIs; ease of use and compatibility with Qt 4 versions."
Guest post by 
Submitted by 
Guest post by 
Submitted by