I’m happy to let you all know that Qt 5.9.0 has just been released. A lot of work has been put into it, making Qt 5.9 the best Qt version we have developed so far.
With Qt 5.9, we have had a strong focus on performance and stability. We’ve fixed a large number of bugs all across Qt, and we have done a lot of work to improve our continuous integration system. This will make it a lot easier for us to create new releases (both patch level and minor releases) from 5.9 onward.
We’ve also added automated performance regression testing to our testing infrastructure, something that will allow us to continuously monitor our work on improving the performance of Qt. Please have a look at the separate blog post for more details.
The new configuration system used in Qt Lite has received many bug fixes, also here, you can find more detailed information in a separate blog post.
Long term supported
One major decision we have taken is to make Qt 5.9 another long-term supported (LTS) release. The previous LTS release, Qt 5.6, is starting to show it’s age, and many users have been asking for a more up to date version of Qt that they can use as a basis for long running projects.
Some of the major changes since Qt 5.6 include more than 2000 bug fixes all over Qt. Additionally, we are now using a C++11 compliant compiler with Qt which has allowed us to modernize our code base. We have also added the Qt Lite configuration system and made significant updates to our graphics architecture. This is in addition to all the other new things that have been implemented in Qt 5.9, explained in the following sections.
As an LTS release, Qt 5.9 will be supported for the next three years to come.
With our improvements on the CI and releasing infrastructure, we are convinced that we will be able to provide you with much more frequent updates and patch level releases for Qt 5.9 than we are able to do for the Qt 5.6 series. As a long term supported release, we will provide you with frequent updates in the first year. After the first year, we will gradually get more and more strict on the changes that will happen in the branch, so as a result, patch level releases are expected to happen somewhat less frequently for the second and third year.
We will as promised also continue to support Qt 5.6, but we strongly recommend everyone starting new projects to use Qt 5.9 as there are a lot of improvements across the board that will be of huge advantage to you.
Lots of new functionality
Even with our focus on performance and stability, we have managed to add more new features into Qt 5.9 than I can mention in this blog. For a more complete list have a look at the ‘New Features’ page in our wiki.
Here are some of the highlighted new features.
Core and Networking
Quite a few new features have been added in the Core and Networking modules. Starting at the base, Qt Core has two new classes. The first class, qfloat16 abstracts 16-bit floating point numbers, as these nowadays are increasingly more important for inter-operation with APIs which make use of the GPU. In addition, a new QOperatingSystemVersion class has been added to conveniently test for the operating system and version your application is running on.
Qt Network has gained support for HSTS (HTTP Strict Transport Security), improving security on HTTPS connections through QNetworkAccessManager.
Our NFC support in Qt NFC has seen some very nice improvements for Android, and Qt Web Sockets can now use external TCP sockets. Classic Bluetooth on WinRT and Bluetooth peripherals on Android are now both supported.
Qt Gui and 3D
Qt GUI has gained a shader cache, that can cache compiled versions of OpenGL shader programs, and we have added support for Compute Shaders. The OpenGL paint engine does now work with OpenGL Core profiles as well.
An enormous amount of work has been done with Qt 3D. Together with the functionality we already had in Qt 5.8, we now have a fantastic 3D engine in Qt 5.9. You can find all the details in a separate blog post by our partner KDAB.
Qt QML and Quick
Quite a bit of work has been put into improving the QML and JS engine for Qt 5.9. We have added a completely rewritten garbage collector, offering better performance and reducing memory fragmentation in the JavaScript heap. The new collector also provides a better basis for further enhancements to our memory management in upcoming Qt versions.
Qt 5.9 also comes with a brand new QML caching infrastructure, offering similar benefits to our users — just like the commercially available Qt Quick Compiler, but in a much more transparent way. The new infrastructure has two modes of operation. In the default mode, the caching infrastructure creates a binary cache of your QML files at the first start-up of the application. Optionally, you can also pre-create that cache at application build time, achieving similar performance and startup time benefits as with the Qt Quick Compiler. Additionally, the new caching infrastructure does not bind your application to a specific patch level version of Qt, as the binary caches are versioned and will get regenerated if required.
Also, a lot of work to improve performance and reduce memory consumption has been done in the engine, making this a significant upgrade compared to our previous Qt 5.6 LTS release.
Qt Quick now makes use of the new OpenGL shader cache added in Qt GUI, improving application startup times. We added an image provider that can share image data between processes, and a new OpenVG backend, allowing it to run on hardware that only has 2D hardware acceleration support.
Qt Quick Controls 2 has added more new features than I can mention here, please have a look at the separate summary blog post, which links to all the details and blog posts on what has been added in Qt Quick Controls since Qt 5.7.
Qt Location and Positioning
For this release, Qt Location has received quite a few new features. We’ve added support for tilting and rotating maps, both through the APIs and through touch gestures. Stacking of maps has been improved, it’s now a lot easier to add overlay items to maps, and we improved the support for blending in copyright notices on the maps.
An entirely new plugin adds support for Mapbox, using their OpenGL based map rendering engine.
A couple of other visual improvements have also happened, like using lower resolution tiles to approximate tiles that are still missing at a higher zoom level until those are downloaded.
On iOS, we improved Qt Positioning, so that it now can collect data even when the application is in the background.
Other modules
Many other modules have also been updated. Most notably, Qt Webengine is now using Chromium 56. Qt Virtual Keyboard now supports external keyboard layouts and many other cool new features.
Qt Gamepad has graduated from Tech Preview status to being fully supported in Qt 5.9. We’ve also added Qt Remote Objects as a new module in Technology Preview status.
There have been significant changes to Qt Wayland that are described in a separate blog post.
Of course, Qt 5.9 also comes with a brand new version of Qt Creator with many great new features. The Qt Quick Designer now contains a built-in code editor, and we now have a completely rewritten the cmake integration. For further details, have a look at the separate blog.
Platform changes
Qt 5.9 adds support for two new platforms. It now supports QNX 7.0, the latest version of the QNX operating system. We have also added support for the INTEGRITY OS, details about this are again in a separate blog post.
Finally, we added support for compiling Qt in a size optimized mode (-Os on GCC), saving around 5-20% in binary size for the Qt libraries and your applications.
Thanks
Finally, I’d like to thank all the people who have contributed to this release. While you can see and follow all the people contributing code through patches to our git repositories, a lot of additional work has happened more invisibly behind the scenes, for example by working on our CI and releasing infrastructure or helping to create collateral and content for the web pages.
I hope you’ll all enjoy this release. You can get it from the usual places, either through your Qt Account or from our download page. Please also don’t forget to give us your feedback, and write a bug report (if you should find one), so that we can improve the 5.9 series even further in upcoming patch releases.
Why not shipping Chromium 59?, they’ve shipped with v8js turbo fan on by default on that version btw.
Chrome 59 is not even released yet 😉
We use the latest Chromium that is available when we go into feature freeze, often even a beta if it is stable enough.
They ship only stable versions (Chromium 59 still in beta)
https://blog.chromium.org/2017/05/chrome-59-beta-headless-chromium-native.html
> Qt 5.9.0 Known Issues
> Ctrl C/V shortcuts do not work in Qt Quick applications
Um, what?
Who cares?
“Qt Quick is not a desktop toolkit” (с) J-P Nurmi
What a stupid comment
You can use ctrl-c/v in Android native controls, not a desktop only function.
Just to clarify, certain keyboard layouts on Windows are affected. As far as I can see, the shortcuts work fine on Windows with the US keyboard layout. I don’t know which keyboard layouts are actually affected. The bug report mentions the Russian keyboard layout.
Oh, it’s not the first problem with keyboard layouts. Keyboard input doesn’t work normally via TeamViewer.
When can I download Qt 5.9.0 by online installer?
I just see 5.9.0-201705291821 version in online installer
It is Qt 5.9.0. ‘-201705291821’ is just a detailed timestamp of the build
Why isn’t there a msvc2017 32 Bit pre build in the online installer?
We cannot offer pre-built binary packages for every possible windows combinations. With Qt 5.9 there is 32 bit ones for minGW and MSVC2015.
Where is the downvote button?
Out of interest: What are the reasons you cannot use the 64 bit compiler?
We indeed have the need to limit the number of permutations of the Windows packages, and the trend looks like 64 bit versions of Windows are prevalent, and applications are finally moving to 64 bit, too …
I have to target older machines which runs 32 bit versions of Windows
No reason, we use 32 bit and 64 bit compilers.
I too would really like to have 32-bit VS2017 binaries. We are shipping 32-bit and 64-bit inside a single installer. Not sure if we can give that up yet.
plenty of our industrial PCs still use windows 32-bit, some were even installed with windows xp..
3rd party dlls without the source code.
Looks more logical to drop MSVC 2013 as Unreal did.
But Qt offers pre-built binary packages for 6(!!!!!!) UWP combinations including 2 for x86 platform. And only 1 MSVC binary for x86. And why 2015, not 2013, 2017? It’s really strange decision.
“But Qt offers pre-built binary packages for 6(!!!!!!) UWP combinations including 2 for x86 platform.”
Because those UWP builds serve multiple purposes. x86 works for x86 desktop, windows 10 mobile emulator, as well as Win10 IoT builds on x86 devices.
Same as the arm build functions for Windows 10 Mobile as well as Windows 10 IoT.
Reason here: also using an industrial PC with 32 Bit OS.
The decision to keep MSVC2015 32 Bit perfectly makes sense: It is one before the latest version, so it will likely not get any compiler-changing service packs anymore. So 2015 is IMO the latest really “stable” version of MSVC 🙂 Plus, the new Qt VS Add-In is AFAIK still in beta for MSVC2017, so MSVC2015 should be the version where most people have a benefit from.
You should switch to Linux anyway.
That kind of negates the point of using a cross-platform development environment.
Hmm, it is very interesting. I tried to migrate my 5.8 project from my current VS2015 to VS2017 and quickly get bunch of errors within Qt framework. I googled a little and found somewhere (sorry, don’t have a link) that all these issues will be gone with the release of Qt 5.9. I quickly ran back to VS2015 and now I have to have two instances of VS, with 2015 only for Qt-based project.
There are questions worth figuring out: What was the main reason to have pre-built libraries for VS2015 to the detriment of VS2017? Will VS Qt assistant work with Qt5.9 in VS2017? Isn’t it obvious that at some point in the next three years Qt Company will have to drop pre-built libs for VS2015, since even now it is not current MS development environment?
What are the errors? Post the details in the forum; perhaps someone will be able to help you resolve them.
The errors that I experienced when I tried to compile my 5.8-based project in VS2017 are now thing of the past, aren’t they? Qt5.9 had just been released and what worries me that the company chose to release prebuilt framework targeting VS2015 and not VS2017. At a time of the 5.9 release VS2015 is a thing of the past, so my concern is that new 5.9 was really tested against VS2015 compiler.
But there are UWP x86 2017 binaries offered, so it really seems like this was just an oversight… at least I’m hoping.
Up to and including 5.8 you supported a range of pre-built configurations for mainstream OS / compilers, such as MSVC2015 64-bit.
I can understand the issue of constantly providing builds for a massive range of platforms and compilers every release, but this being the LTS release it would seem sensible to at least provide the same ones you had for 5.8.
> Up to and including 5.8 you supported a range of pre-built configurations for mainstream OS / compilers, such as MSVC2015 64-bit.
We do still provide binaries for 2015 64 bit and 2015 32 bit. What we don’t provide anymore is 2013 32 bit. We instead added 2017 64 bit.
> I can understand the issue of constantly providing builds for a massive range of platforms and compilers every release, but this being the LTS release it would seem sensible to at least provide the same ones you had for 5.8.
You could also turn the argument around: _Because_ it’s an LTS it was rather important to support MSVC 2017, instead of an older version that will be less and less important as time goes by.
> We cannot offer pre-built binary packages for every possible windows combinations
Why not?
This is a poor choice. Seriously, better drop MSVC 2013 instead and give us 32-bit MSVC 2017. Most of my pet projects as well as smaller tools I make at work are shipped in 32 bits only because then I have much less headache with setting up dual build (32 + 64), and no one complains about compatibility. And the main piece of software I’m working on, one that requires large RAM address space as well is performance, is shipped in 32+64. There are still a few users who have Win 7 32-bit, and even Win 10 32-bit. Additionally, many small PCs, especially Intel Atom-based tablets and sticks, use 32-bit Windows 10.
Bottom line: because you don’t provide 32-bit 2017 build, I cannot switch most of my projects to the new compiler. Very poor decision, Qt staff.
MSVC 2015 binaries are binary-compatible with MSVC 2017. Could you use the 32-bit MSVC 2015 binaries with your MSVC 2017 compiler?
Are they? Is it documented (i. e. guaranteed) somewhere?
https://bugreports.qt.io/browse/QTBUG-61053
What is the criteria of measuring priority in the issue tracker? This bug is marked with “P0: Blocker,” but why the fix is not applied to the final release????? Then, what is the purpose of tagging such priority?????
Disclaimer: I am using COMMERCIAL Qt licensing.
@Choi: QTBUG-61053 will be part of Qt 5.9.1 release. The fix is available, but did not make it in time for Qt 5.9.0. If you need to use https on iOS, you need to wait Qt 5.9.1 release or build yourself with the fix.
Why have you changed the priority from P0 to P1 just when you responded to that comment?
Because Qt 5.9 has already been released. As such, by definition the issue is not a blocker anymore (P0, blocker, means to actually delay the release, which has already happened).
Hmm… So “P0: Blocker” issues should not be in the release versions, right? So, the decision you guys made was just change its priority to lower ones, instead of making fixed versions…
It seems that my question has been answered. The criterion of giving priority for each issue is to make released versions “look” stable, not measuring the “importantness” of each issue. If the priority is for measuring the importantness, then it had to be leaved as “P0: Blocker”.
As one of the Qt lovers, please take responsibilities for making Qt in a better way. Releasing stable versions without solving all critical issues could happen in some cases, but I think this decision that just changing priorities is not a right way. Please take steps to make this happen less than now.
Okay… Could you tell me when will the Qt 5.9.1 available? Several critical bugs introduced in Qt 5.9.0 make me impossible to use for the application development.
Although Qt 5.9 introduces a large amount of great new features and performance improvements, it seems that the 5.9.0 version is one of the most unstable release I’ve ever seen. Since Qt 5.9 is chosen as the new LTS version, please kindly consider the stability and reliability more carefully…
We are targeting to get 5.9.1 out during June, see https://wiki.qt.io/Qt_5.9_Release
Oh, I see. Thanks for your reply.
Qt is a non-blocking framework: https://bugreports.qt.io/issues/?filter=18388
I’ll second that. This bug is essentially a showstopper for us as well. If you’re delivering a Qt SDK, now you’re in a position to have to tell your customers to avoid 5.9.0 on iOS or build it themselves. You can’t build the networking library for end users since there are export restrictions with ssl/encryption libraries.
There are no any web widgets on MINGW version of Qt. Is it will be available in future ?
i have a same question
Congrats. Looks like a great release!
Link doesn’t work: http://blog.qt.io/blog/2017/05/31/ready-made-ui-controls-with-qt-quick-controls-2-a-summary
Wow! Now this sounds like an epic Qt release 🙂 Still need to follow all the referenced blog posts about all those exciting features. As always: great work!
What about dynamic linkage of Qt binaries for iOS to support LGPL3? Is this feature available in this release?
Sort of / not yet. You can manually create a dynamic libraries build by passing the -shared option to configure when building Qt for iOS, but the support for automatically bundling the Qt frameworks into your application bundle is not finished yet. This doesn’t result in the best developer experience, and as such we haven’t called the shared libraries support official yet and continue to deliver static builds through the online and offline installers for now.
Note that you can link statically to LGPL libraries, as long as you provide the object files of your application for relinking : https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic
Thanks, nice to know this, I favor static link better than dynamic link(except of runtime plugin), it is way more easier to deploy, solving dependency problems of different libraries are no fun at all
Very nice release as allways! For me it is way easier to use msys2 than the official Qt installer because of all the additional available packages. You guys know of qpm? Would it be possible for the qt company to provide a general purpose c++/qml package manager?
Holy shit nice redesign of the website BTW!
Congrats for the spectacular release! What about QtQuick on Web via emscripten/nacl? Is it still developing stage or discontinued?
NaCL is going to be removed in a future Chrome version: https://developer.chrome.com/native-client/migration
What about emscripten?
AFAIK, not going anywhere because that is not part of any browser, just a third-party tool to convert C++ to other web-friendly languages.
NaCL and asm.js is deprecated, there will be a standard WebAssembly: http://webassembly.org/roadmap/. Emscripten toolchain, used to compile into asm.js specification, should compile C++ into WebAssembly. Check this CppCon video: https://www.youtube.com/watch?v=jXMtQ2fTl4c
> The previous LTS release, Qt 5.6, is starting to show it’s age
its
Fantastic.
Great Job Boys.
Could you guys help us please to find more info on these topics mentioned in this blog-post:
– “Optionally, you can also pre-create that cache at application build time, achieving similar performance and startup time benefits as with the Qt Quick Compiler. ” – how would one do this(it says “Optionally”)? Are there docs on how this works and how to do this?
From this phrase I understand that it should be something similar to resource files, where you have to do additional steps in order to compile-in the resource file.
– “The new infrastructure has two modes of operation.” – are there docs explaining what each mode does and how to use it?
– “We added an image provider that can share image data between processes, and a new OpenVG backend” – where can we find docs about this image provider and this new OpenVG backend?
If docs do not exist, even links to Jira issues would be helpful.
For the OpenVG backend, see http://doc.qt.io/qt-5/qtquick-visualcanvas-adaptations.html and especially http://doc.qt.io/qt-5/qtquick-visualcanvas-adaptations-openvg.html
The pre-populated QML cache setup is explained under http://doc-snapshots.qt.io/qt5-5.9/qtquick-deployment.html#qml-caching-for-deployment-preview.
For some reason the non-snapshot documentation is not up-to-date yet.
Is there a way to use it under QBS based project?
Not out of the box so far: https://bugreports.qt.io/browse/QBS-1132
Here are the docs for the shared image provider: http://doc.qt.io/qt-5/qt-labs-sharedimage-qmlmodule.html
Come on, guys.
The Bugs
https://bugreports.qt.io/browse/QTBUG-59704
https://bugreports.qt.io/browse/QTBUG-59256
are still not fixed although there is a patch available.
iOS Apps using https requests are also not working at all.
So why you release Qt 5.9 which is simply broken and not useable at all?
They are not P0 bugs, so there is no need to fix them, isn’t it? On the other hand, a P0 bug can be easily changed to P1(like it was done with QTBUG-61053) and will not prevent release.
> So why you release Qt 5.9 which is simply broken and not useable at all?
Because it’s usable. Maybe not for the one’s affected by the bugs, but for many others.
Trust me, nobody is keen on releasing something with known bugs in it. But reality is, Qt is a large ship, and overall I think it’s better to release on time (even if there are known issues, which we’re open about) and have frequent patch level releases than postponing a release for too long.
Thanks for this explanation. This is something that I can understand regardless of whether I agree or not. In JIRA, P1 is defined as a blocker. But it seems that you see only P0 as a blocker. I think you need to update the definitions in JIRA.
There are more than1000* unresolved issues (P >= P2) affecting 5.6, about 350** (again P >= P2) affecting 5.9. Even if 90% of those issues are invalid, that makes 100 legitimate issues for 5.6. In fact, 131 of those ~1000 issues are P0 or P1.
I really hope that quality becomes more important than quantity (in terms of number of modules/features/platforms/graphics backends/QQ Control reincarnations etc.) for TQC. You have been prioritizing quantity for a way too long time for reasons I can only guess but it needs to change for a while if you really want to reap the benefits of this rapid expansion in the framework.
* https://bugreports.qt.io/issues/?filter=18729
** https://bugreports.qt.io/issues/?filter=18728
Hey, where’s the MinGW binaries for Windows?
Those are Included in online installer or in combined windows offline package
Nice to see QT 5.9 is released but I hoped Qt 5.9 has BLE support for Windows. Do you know this feature become available in future releases?
BTLE peripheral mode is supported on WinRT (see http://doc.qt.io/qt-5/qtbluetooth-index.html) which you can deploy to all Win10 platforms. If you are talking about Win32 support then I am afraid there is no schedule for it at this stage.
Hi,
is there a way to get a pre-build MSVC2013 32 Bit build? The installer includes binaries for MSVC2013 64 Bit or MSVC 2015 32Bit.
Thank you!
No, we aren’t delivering pre-built binaries for 32 MSVC2013 from Qt 5.9.0 ->
Would there also come a replacement/new implementation for the “ToggleButton QML Type”?
Hi, would you expect it to look or behave different to Button { checkable: true }, which equals to the looks of the Material design ToggleButton on Android, and Universal design ToggleButton?
Happy about the release, but would like to see Qt Gamepad actually work with more than 1 gamepad before it’s paraded around! It literally is designed for just one and there are no plans to make it work with any others… (https://bugreports.qt.io/browse/QTBUG-57389).
OK!
I build Qt5.9 via Buildroot for IMX6 board and try run some simple apps. But I have no success.. 🙁
Out message was:
QML debugging is enabled. Only use this in a safe environment.
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-root’
EGL library doesn’t support Emulator extensions
Aborted
https://bugreports.qt.io/browse/QTBUG-61156
Great work, guys! But I think this release is not good enough to be release. I hope existing problems will fixed soon.
Something changed with QString conversion to string (C++ to QML calling a Q_INVOKABLE C++ method)?
My whole application cant start because ‘endsWith’ of object QString is not a function.
Hello bnogal, could you please write a bug report about the issue.
Ok, after doing a clean test. I verified it is of course working.
Problem was that after change to Qt 5.9, not all the makefiles were updated. I will have to review my .pro file.
Remove makefiles, regenerate them and everything is fine.
To go against most previous toxic comments: thanks for your work, the open source version is just perfect, until you try to go against the framework!
There was announcements in previous blog posts about qtpdf and the (long awaited) Qt Quick PathItem to draw vector graphics in Qt Quick scene graph: What is the status of theses sub modules, will they be part of a later 5.9 release?
We don’t add new features in patch level releases, so no, they won’t be part of 5.9.x (but potentially Qt 5.10…)
Thanks for this release. With 5.9 being an LTS, I decided to upgrade from 5.6.2, and all I had to do was to replace a few calls to QModelIndex::child() (which is now obsolete) with calls to QAbstractItemModel::index(). Yeah! 🙂
Better not unless you need those new features, I will stick with Qt5.6.2 until Qt5.9.x are less complaint(bugs, bugs, bugs and bugs). I like new features, but stability is much more important than those new features for me.
Well, we want to replace our use of QwtPlot with that of Qt Charts. So, to move to Qt 5.9 LTS actually makes sense for us. I just hope that the GUI glitches we have identified can be fixed relatively easily at our end…
FWIW, part of the glitch I am talking about is described at https://bugreports.qt.io/browse/QTBUG-61092.
+1 for more bugfixes and less feature pumping.
The Ableton guys made this choice in 2010 and it really, really, gave them a better brand recognition (http://cdm.link/2009/12/ableton-suspends-development-to-focus-on-bug-fixes-for-live-8/)
When will Qt 5.9 installer contain VS2017 32-bit binaries? Thanks.
Hi arbilence! Unfortunately we aren’t planning to deliver 32-bit pre-built binaries for MSVC2017, sorry
Can you supply the way or document how to compile VS 2017 32-bit binaries? thanks.
Hi, There shouldn’t be anything special with MSVC2013, general instructions here: http://doc.qt.io/qt-5/build-sources.html
Is it purely maintenance or other internal company issue or Qt 5.9 is not fully supported on VS2017 compiler?
Thanks!
VS2017 is fully supported for Qt 5.9. There’s a compiler issue for static compilation though, see https://bugreports.qt.io/browse/QTBUG-59721
Thank you! My assumption now is that pre-built Qt for vs2017 will be available after this bug is fixed.
Hi, There is already pre-built binaries for MSVC 2017 64 bit both in online and offline packages. And we aren’t planning to add more pre-built binaries anymore (if you are referring 32 bit ones for MSVC2017).
Our applications build and run on the 32-bit windows system, and we plan to update Qt to 5.9. Can you supply the way or document how to build VS2017 32-bit binaries? Thanks.
Thank you, guys.
Amazing update! I have a question: It is said on the 5.9 home page “Fully supporting both traditional Win32 applications and universal apps. ” But acutually windows XP is not included, right?
Right, we don’t provide any binaries anymore that run on Windows XP, or anything older.
Hi,
Why Qt 5,9 for Android and IOS not exist in download.qt.io ?
Regards
It’s available in the online installer for the host platform (at least that’s what I’m trying to install now ;)).
If you refer to the offline installers: Android and iOS are now part of the respective platform installer.
MSVC2017 static builds still do not work, since 5.8, nice release.
https://bugreports.qt.io/browse/QTBUG-59721
We are very happy to receive this release, thanks for the great job!
But it would be extremely helpful if you can realese pre-built x32 binaries of msvc 2017 🙂
Would there also come a 32-bit pre-built in the online installer?
We aren’t delivering pre-built binaries for Linux 32 bit anymore
Thank you for the VS2017 support. Wondering if the plugin for VS is also updated to work with VS2017?
Visual Studio Add-in I mean.
Qt Creator 4.3 keeps crashing (approx 8 times yesterday I’d say)
Didn’t have this problem with the previous version.
Please report this to the bug tracker: https://bugreports.qt.io/projects/QTCREATORBUG . Please include the dump of Help > System Information, and what you did before Qt Creator crashed.
Agree. Qt Creator 4.3.1 and 4.3 crashes quite frequently. Quality of Qt lib and Qt creator is going down 🙁
Tied of new features instead of quality policy. That should be stopped
Bugtracker is just a heap of bugs … only P0 and P1 have chances to be seen. Other are just ignored for years. Try to find the most old bug in the system. You will be amazed how old it is. Nobody cares to mark it as closed or fix it or just do anything with this. Such attitude to bugs does not make us even be willing to fill them! 🙁 … because finally … nobody cares (proven by several real examples)
@Vivi: It is unfortunate that you feel our latest releases are not how they should be. While there are multiple open bugs, we do fix bugs as well. Quite a lot actually. We do also try to find the most important ones to fix – those that affect high number of users, ones without a sensible workaround and ones that high the highest impact. While most of the work is done by Qt R&D, we also do have a possibility for you and others to help fixing bugs and contributing back to Qt.
Attitude to bugs from Qt’s PM is generally poor. PMs consider devs are just for R&D. Respect to bug-reporters is very low. Bugs can stay in commited state forever. Nobody knows if it was seen and excepted or not. Because who cares about bugs. Devs are just for R&D and they do not what to see many opened bugs, right? They just do no mark them as such (you can even read in channels how they say that it is OK not to mark the bug as open 🙂 … very funny attitude). We also see cases then bugs are closed while problem is still exist … my favorite is Qt Creator’s message “The build directory needs to be at the same level as the source directory.” … which is about bug in qmake … and as I see in bugtracker bug was closed! But why we need that bug opened? Let’s just show info which describes a bug. Very slicky way of doing things.
I am sorry i cannot build my apps for android from my Linux machine.
I know Google changed something in Android SDK and tools from Qt are useless in helping me.
Please in the next release fix this.
If i can compile for armv7 i think to buy a small qt license ( because i am small too :))
Regards