Qt 5.3 Alpha Available
February 27, 2014 by Lars Knoll | Comments
I'm happy to announce that Qt 5.3 Alpha is available for download. Qt 5.3 is coming out a bit earlier than our regular 6-month release cycle would've forecasted, as we have decided to pull forward our release cycle meaning, starting from Qt 5.3, future Qt releases are planned to happen every Spring and Autumn.
The focus for Qt 5.3 is mainly about improving the stability, performance and first-time user experience of the product. A lot of the work over the past months has been focusing on improving the quality of Qt, especially on the mobile platforms and Mac OS X. Having said that, Qt 5.3 will also offer a good amount of new and exciting features, and a new platform: WinRT/Windows Phone!
New features
One of the main new features in Qt 5.3 is an improved integration between Qt Widgets and Qt Quick. The new QQuickWidget class allows seamless integration of Qt Quick-based user interfaces with a Qt Widget-based application. This should significantly simplify using both technologies together in one application and provides an easy way to migrate Qt Quick into existing Qt Widgets applications.
Qt Network gained support for the SPDY protocol, speeding up of web content download in Qt WebKit and through QNetworkAccessManager. A new Qt WebSockets module got added featuring full support for web socket (RFC 6455).
Qt QML and our new QML engine (introduced in Qt 5.2) will with Qt 5.3 support profiling using the QML profiler in Qt Creator. In addition, you will be able to profile and debug multiple QML engines inside one application using the new EngineControl debug service.
Also, Qt Quick gained a Calendar Control and a Dialog template that includes standard buttons.
Qt on Windows can be configured to allow runtime switching between desktop GL and ANGLE.
Mobile-Specific Features
A lot of our focus is on fixing bugs and smaller improvements for the mobile platforms, both on the framework and tooling side. In addition, a couple of new backend implementations for existing modules have been included. We have added Bluetooth support for Android and Qt Positioning is now fully supported on both Android and iOS. Finally, input methods such as Chinese are now supported also on iOS.
Support for WinRT and Windows Phone
To complete our mobile offering, Qt 5.3 will include support for WinRT and Windows Phone on a beta quality level. Most features in Qt Core, Gui, Network, Widgets, Qml, Quick, and Sensors are working already, and we will focus on improving them towards the final release.
More details of the new features in Qt 5.3 are available in the wiki.
Qt Creator
In addition, we are planning to include the upcoming Qt Creator 3.1 release into Qt 5.3 final, adding quite a few new features on the tooling side. Qt Creator 3.1 will also include initial support for WinRT and Windows Phone.
As usual, the Qt 5.3 Alpha release is available as source packages that can be downloaded from the Qt Enterprise Customer Portal, and the open-source version from Qt Project.
Blog Topics:
Comments
Subscribe to our newsletter
Subscribe Newsletter
Try Qt 6.9 Now!
Download the latest release here: www.qt.io/download.
Qt 6.9 is now available, with new features and improvements for application developers and device creators.
We're Hiring
Check out all our open positions here and follow us on Instagram to see what it's like to be #QtPeople.
Commenting for this post has ended.
Qt lacks of several features other competitors framework offer since years: integrated orm (entity framework on M$, hibernate on Java), web site framework(mvc and web forms on M$, jsp and jboss on Java) and a package installer integrated on IDE (i.e. nuget on M$). If you really hope someone will use Qt in production environment you should develop features that other frameworks offer...
hey Unknown, you've got to be kidding. Qt is first and foremost a desktop application UI development framework. The last thing I want is for Qt authors to suddenly start developing yet another web framework.
On Windows there's an awesome opensource installer InnoSetup, it is de-facto an industry standard on Windows (the only other one that I see used a lot is MSI, but it's not always convenient or even available). Use it. Mac OS and Linux have their own application distribution systems. A Qt installer is damn close to the top of my list of the least useful things in the world.
Qt works awesomely in production environments (as long as bugs don't appear. It's irritating that Qt 5 was unusable in my project until (hopefully) version 5.3).
I spoke about ORM and a web presantational layer. It's NOT something you HAVE TO use (like any other Qt module you're free to not include in your prj). But if you just know you'll need it, what you're gonna do? Use another framework that just has everything you need! Do you really would use QSqlDatabase wrapping any db tables into a class obj by hands? Even if you have hundreds tables? There're ORMs that just do it for you. About nuget i was too vague. We're reinventing the weel every time some "widget" doesn't fit our needs. Qt Designer just provide a way to extend it. If Qt developers would bring it to a "comunity level" with a "package installer" you'll can download a customized widget that does something amazing someone else just developed, like: QCalendar. Qt troll just did it, what's the pro to do it again and again? Now suppose you can download packages developed by a whole comunity of Qt devels...A repository with customized "widgets".
Like you'd be better with Hibernate?
You'd need a XML config for everyone of those tables, and a class implementation as well.
On which year you're living? hibernate this days is the defacto JPA implementation and you will only use xml if you want (it isn't recommended anymore since JPA 2). But I don't think any such a thing belongs to QT, not even any web server stuff better left to an appropriate C++ library focused one each focused on each thing
You have Wt (http://www.webtoolkit.eu/wt)) inspired by Qt to do web sites.
Dude all you said is available with third party libraries, ORM
you have QxORM and ODB C++ which offers Qt integration.
For webframeworks you Cutelyst (https://gitorious.org/cutel...), QDjango, TreeFrog and Tufao.
So yeah Qt Rocks :)
Now I've got your idea about 3rd-party widgets gallery. That would indeed be cool.
I too criticize Qt for not having a good web server component, but it's really not that big of a deal. It is a glaring omission, but the amount of glare is decreasing because the QJson* support is now present, and nearly everyone speaks JSON.
Qt is so good I still want to do web servers in it, and fortunately it isn't that hard. The biggest barriers are knowing how to use QRunnable and that Nokia removed QHttpHeader and its subclasses. You can find those elsewhere.
ORM is similarly very easy to get going thanks to Object. I wrote a ORM in a few weeks that took a XML definition (which was a custom definition) and spat out the ORM classess for that schema.
So yes, your points are valid, but the challenges are not insurmountable. Qt has benefits that more than make up for the deficits, which is why I choose use it.
I'm not saying that i Qt is evil and that i'll never use it. I use and i love it! Anyway it lacks some important features.
Whenever you're not just playing with 2 or 3 db tables, or your customer ask for an integrated web app you're obliged to choose a different framework.
Create a custom system that just wrap some RDBMS tables is not that difficult, but a whole ORM that could let you wrap every tables into a class with graphical relation design, let you modify the model with graphical interacion or viceversa, (and so on) with ANY RDBMS is a different matter. Or are you state that ORM are useless? :)
The whole programming "world" is going toward ORM and web framework direction...maybe there is a reason...
This is exactly why I created QxOrm library and QxEntityEditor application for Qt developers !
With QxOrm and QxEntityEditor, you can manage hundreds tables without any difficulty.
Thanks for this! I was just embarking down the road of creating an ORM without really knowing what I was actually creating. Will check out QxOrm instead!
Have fun with https://gitorious.org/cutelyst
I have implemented a simple hibernate system. Unfortunally i did for some projects i have do develop in my actual job... I was asking about the chance to make it GPL, but not luck.
I just can say you can make something quite nice, in 2-3 weeks counting testing, metaobject system is giving almost everything you need, the rest is decltype and a couple of templates to make everything easier to use.
i am even thinking about making a better version in my free time... ones, when i have holidays... LGPL taste.
This is great news!
Are there any plans for native Qt Quick controls for the various mobile platforms?
Thanks again!
Any news about treeview in qml? Should we expect it in upcoming Qt 5.3?
@DimanNe: No, Qt Quick TreeView is not part of Qt 5.3.
When can we expect a tree view? It would be very useful! I know that there is some question about how a delegate would look, but that could be separated into a open button delegate and an item delegate.
I really don't care how, i'd just really like to directly use a tree model directly without using a proxy model to make it into a list model just to use it in QtQuick.
Like the QuickWidget addition, as it allows current Widget apps to move to QML without a lot of disruption, then can go piece by piece. Very nice
Congrats !
Too bad that the Location module (with or without Qt3D) didn't make it for 5.3, I'm tired of my custom-made maps based on QGV... Is there any chance for it to be released as a preview before 5.4?
Also, I would appreciate a comprehensive example on the scene graph module (think chip demo) to get started with it...
Anyway thanks for this new release
Is Qt 3D a part of this release?
Where is the Printing overhaul?
@scorp1us: Printing improvements are hopefully finalized by beta, API changes for it are pretty much there already. Qt 3D is not yet ready.
I think that there are a preview of a new api in repo:
https://qt.gitorious.org/qt...
Check the newapi branch.
great news!
just loved the new QtWebSokcket.
is there any plan to add a simple Web framework add-on?
something like: https://github.com/vinipsma...
I would like a web framework as well, and Tufao is a good start. I have a web server in Qt, and I basically had to reinvent most of what Tufao has. I have only 3 problems with Tufao, which is why I continue to use my in-house server.
Qt also lacked a few features that I had to implement that seems to belong in Qt's domain, and all of which the Tufao author would want due to his inspiration from the Node.JS API:
It would be nice to have those in Qt, plus a more robust (read: works between threads) version of QTcpSocket. I think the rest would fall into place in external frameworks like...
I too have my own web stack, it is super simple though to do, once you know how to to it.
LibQxt has a very capable server as well.
However static linking with LGPL is permitted. It is ambiguous with GPL, but Linus Torvolds is ok with it. I've followed the static linking debate for some time.
Yes, the build system of libqxt made it a bit difficult to do cross platform development when I looked at it the first time, so I didn't look at the web component of libqxt as much as I should have. It actually has almost everything that I would want minus WebSockets, which shouldn't be too hard to integrate with the Qt 5.3 implementation. The build system problem may not be an issue if it's tweaked a bit to:
1. Only builds the web, network, and core components.
2. Install into the Qt install tree instead of the host system's install tree.
I think it's about time that I give libqxt another shot.
There is a growing concern that I see, however. On the server the thread affinity of a QObject dictates which thread will be used to process signals sent to that QObject. In my server, and most that I've seen, there's a thread pool, which means that signals ucan't be used for the most part. I think that a second type of "QueuedConnection" is necessary...
Check out QML Web.
https://projects.kde.org/pr...
Where are new features for QtWidget and Desktop-UI relevant features in QtGui?
Are you still forgetting your beloved trusted desktop userbase?
Please don't forget us and do some work there too. Some suggestions: A nice QCollectionView class, faster QTableView, etc.
Oh and regarding QtSql: SQLite gains more popularity every year, why is it still not handled as a first class citizen?
Notification and many other nice features are just not implemented in the Qt SQLite driver.
But seriously, do not forget the desktop!
@Soc: QQuickWidget, runtime switching between desktop GL and ANGLE, as well as network improvements are very valid for desktop users. In addition many smaller improvements directly benefit desktop - so no worries - we are certainly not forgetting our desktop users.
Are there any plans to extend Qt's Bluetooth support so that it can be used on OS X and Windows? As I understand it there is support right now for Linux and Android. I imagine that once once it works on iOS adapting the code to OS X won't be that much work anymore.
I'm really excited to start using Qt.
My only hang up is no google maps. I've never made an app that didn't require a map.
Please add google map support ASAP!!!
Love the work, thank you so much.
http://www.ics.com/company/...
The transition from Qt3 to Qt4 was so much smoother than Qt4 to Qt5 so I hope that this is taking the opportunity to fix as many annoying things as possible.
Currently missing is full support for High DPI displays: my software looks terrible on a Retina Mac. It's several years since Retina displays started to become available on the desktop - and it's not only Macs that have them.
Qt 5.2 fully support retina/high dpi displays... There has been blog posts about it, and I'm using it in my application.
"Qt 5.2 fully support retina/high dpi displays"
Please tell me how to use high dpi images in stylesheets and draw high dpi custom widgets with QPainter.
Or give links to the blog posts where these things are explained.
As far as I know, Qt 5.2 only supports standard widgets at high DPI.
Qt5.3 still lack in app advertisement api for android and ios, if Qt team want to make Qt become popular to the developers, this is a very important feature.Many developers of android and ios leverage the advertisements to monetize their apps with ease of use api, how could you persuade those developers to adopt Qt if Qt lack of the cross-platform(android, ios) advertisement api?
Yes, Qt can do that if you know how, the users "only" need to know how to combine c++, java, jni, objective c, basis of android development + platform specific api, basis of ios development + platform specific api. Don't you think this is too complicated for many applications developers?How could you attract those developers to adopt without ease of use advertisement api?
App launching time improved? I have to wait 1-2 seconds for the first UI appearing. That's absolutely unacceptable.
In App Purchase!
In-App Billing!
Will Qt 5.3 come with binaries for VS2013?
@Jonas: Yes, that is the plan.
Hey I love Qt and it rules on the desktop, but there are still anoying things on the mobile platforms, especially when it comes to Android:
I have workarounds/classes/libs for it created, but it sucks, cause other frameworks deliver this functionality for free
Don't get me wrong, qml coding is fun and is much more effective, faster and easier than using this XML/Ui shit on the awkward Android Framework and I'd love to use Qt more on this platform, but other frameworks do better on this basic things
Hi,
OpenSSL absolutely works and has worked since the initial release (Qt 5.2). However, since OpenSSL is not part of the Android NDK, you need to include the libraries as part of the deployment to be sure your application works on all devices, just like on other platforms. Here's the documentation on how to do that: http://qt-project.org/doc/q...
As for the other entries in your list, please make sure bugs/suggestions are registered in Jira, otherwise there's very little chance any of it will be addressed.
Integrating a native web view on Android and iOS is a work in progress currently, but if you have specific use cases for this, then please don't hesitate to comment on the task and describe them. There are unavoidable limitations to any approach for this problem, and while we have some idea of use cases for a integrating web content, I don't think we have the full overview.
Hi Stefan,
Debugging work terrific from my ubuntu-12, 32-bit environment.
Openssl run-time is enabled by default starting from
5.2; thus, provide openssl static libs with arch dep in your pro file.
Take care!
Can somebody please tell me what does it mean that the Qt WebSockets is "an add-on module" (that's a quote from the "what's new in 5.3 " wiki article)? Does this mean that if i want to use QWebSocket in an application i'll have to somehow enable the Qt WebSockets module in a special way instead of just using QWebSocket like e.g. QUdpSocket etc?
@gyll: Add-on definition is more related to delivery and supported platforms than usage: "As opposed to the always required Qt Essentials Modules, the Add-ons can be included optionally in Qt enabled platforms." More at: http://qt-project.org/wiki/... (which seems not yet be updated to mention websocket).
@Tuukka: Oh, yeah, right, sorry, completely forgot about this core/add-ons thingie, thanks. I guess i'll file a suggestion to have this included in core though, websockets should be a mainstay of any serious framework, after all this is a must-have for any high-paced (e.g. multimedia, etc) HTML5 GUI
There seems to be a problem which has been unresolved for some time, concerning qt online installers and RHEL based distros (RHEL, CentOS, Oracle Linux, etc), even the latest 6.5.
Basically one can launch the installer the installing process finishes with a success, but at least Qt Creator and Assistant fail to launch with a following type of an error:
"GLIBCXX_3.4.15` not found ( required by...."
The issue has been discussed, for example:
http://qt-project.org/forum...
but one's mileage may vary and I think that fiddling with the system is not a proper solution if there were an intelligent solution to fix it.
What makes the situation ugly is a fact that RHEL distros are very conservative (which is good in a way) and ship with rather old compilers...one cannot even get the thing (5.2.x, 5.3) to compile (one can compile Qt Creator with 4.8.5, but some features disabled).
I've found that one can get a toolset for RHEL, which is an additional...
...set of more up-to date compilers and utilities for RHEL. Red Hat Developer Toolset 2.0 comes with GCC 4.8.x, for an example. Using the mentioned, I've successfully compiled QT 5.2.1 on RHEL 6.5.
Could it be possible to compile the software you release with a system mentioned or similar to make the number of supported distros many as possible (I'm not honestly sure whether it is even possible to use binary distribution of QT 5.x, compiled with devtools, in a system without devtools and older compilers)?
Many developers use RHEL-based systems and they are left with old versions of Qt because either installing or compiling the latest Qt is impossible.
We are currently working on getting RHEL 6.5 into our CI. Once we know the steps needed, those are going to be documented in our wiki and we will start enforcing the builds to actually pass every time.
Any idea if there will be something new in this 5.3 release for Qt Enterprise users?
@Richard: Yes, we have things under way to be released before or in conjunction with Qt 5.3. In addition the existing Qt Enterprise value-add functionality and tools are or course available and tuned for Qt 5.3 and Creator 3.1 as well. Stay tuned :)
I'd like QT team to put some effort on deployment aspects, especially for qml under windows.
It is often difficult to run programs on machines different from the development one and you have to trial n error to find needed dependencies.
Also you are often bound to add heavy dlls for features you may not need (ICU, network...), adding megabytes to your distribution package.
Please change the recommended deployment method for Android. We just realized that it is the source of all the performance problems we have been having.
Currently the default option you have for cross platform Qt Quick apps (qtquick2applicationviewer and associated deployment code in qmake) causes QML to be loaded from the filesystem which is hideously slow on many android devices. Even on fast devices it is a large time sink.
The solution is to load all QML from the Qt Resources system.
Our app, which loads maybe 10 QML files at start:
Nexus 5 startup
QML from filesystem: 980ms
QML from resources: 470ms
Huawei Ascend Y300
QML from filesystem: 9800ms (yes almost 10 seconds!!)
QML from resources: 2900ms (two thirds speedup!)
And it extends past that. Deploying QML as files causes huge delays when they are loaded, which makes for a terrible impression of Qt on mobile. Please put it in your documentation that the way to deploy QML is in the resources.
Good news on this: The Qt Quick application wizard in Qt Creator 3.1 is now generating applications which deploy via resources instead of via files.
This allowed us to make the pre-generated application code much leaner. In that occasion we also added .qrc handling to the project tree view. You can expand a .qrc file, add prefixes and files, etc.
All the above was summarized in the Qt Creator 3.1 changes list with a short and perhaps slightly too modest "Simplified Qt Quick Application templates (QTCREATORBUG-11264)" :)
Great news!
I fear some people may have been scared off by the poor performance from their first try, but great to hear it is now fixed.
Another piece of good news in this respect is that in Qt 5.3, the assets file engine should be about as fast as loading from resources, so this is now fixed in both ends. I would still recommend resources for most use cases, as this is a cross-platform approach and does not need special platform deployment rules in the .pro files, but for some special use cases, the assets engine might be preferable.
The main problem with the assets file system on Android is listing directory contents. It's a long-standing known issue with the Android APIs and the recommendation is to include pregenerated directory listings to work around the bug. In Qt 5.3, such a listing will be automatically generated by the deployment tool when you create your application package, which means that the assets file engine will have a prepopulated cache and will not be dependent on the speed of the platform APIs.
Some numbers here for those who like that kind of thing:
https://codereview.qt-project...
Gentlemen,
You are doing a great job, especially Android people with thanks to Eskil and BogDan.
Unfortunately, iOS port is lagging far behind Android port with many issues open and not treated.
The most serious one is a broken support for OpenSSL as for external library with QTBUG-36891 being filed but not sure the iOS team recognizes the severity of this issue.
Thanks!
What about QWebEngine?