Qt Creator 3.1 beta released
March 04, 2014 by Eike Ziller | Comments
We proudly present the Qt Creator 3.1 beta release today. This release introduces new features, as well as a whole bunch of bug fixes and improvements. About 1100 changes went into our repository since the 3.0.1 release, from around 45 authors. Many thanks to all who contributed so far!
Reading the git log is a bit boring (believe me ;) ), so you find a summary in our change log, and I'll highlight a few things here.
I think one of the most important things is that we finally integrated experimental support for a Clang-based C++ model. You might know that Qt Creator has its own code model, which has for example the advantage that it is very fast, but the disadvantage that this is traded for some correctness. You might also know that Clang, the LLVM front-end for C/C++/Objective-C/Objective-C++ provides a library that can be used to integrate it, for example, into IDEs. That has the advantage that it is correct (after all it's the base for a compiler), but the disadvantage that it is not very fast. We have been talking about integrating Clang into Qt Creator for a long time, and also had an experimental branch for it, and now we finally have integrated it as an option into Qt Creator.
So, in Qt Creator 3.1 you have the option to base highlighting and code completion on the Clang code model. The global indexing and navigation features are still based on the internal code model, so we still benefit from its speed and error recovery. To enable this feature, you have to enable the plugin in Help > About Plugins > C++ > ClangCodeModel, and tell Qt Creator to use it in Options > C++ > Code Model. The binary builds that we provide already ship with everything necessary for this to work. If you build Qt Creator from sources, you should have a look at the plugin's README.
Another big change is that we drop support for GDBs that do not support scripting through Python. The most relevant GDB that didn't support it, was the version provided by Apple, and they dropped support for it with Xcode 5 as well. Please use the LLDB integration in Qt Creator on OS X.
On the platform side of things, QNX now supports the pretty printers for debugging, added pages for managing debug tokens and runtime configurations, and many other things. Aside from many fixes in the Android support, installing the necessary parts for Android development became easier, with download buttons for the various parts from the Android toolkit. We also improved the support for the Java-parts a bit, with a minimal, specialized editor for Java files, that at least does some indentation and completion of keywords.
Also notable is the experimental Beautifier plugin, which allows you to apply different external source code formatter on your files. It currently has support for Artistic Style, Clang-format and Uncrustify. Many thanks to Lorenz Haas for contributing this!
Otherwise many issues with the QML Profiler have been fixed, debugging with LLDB got more features working, and there also is a new Load QML Stack context menu item in the stack window, that allows you to load the stack of the QML parts of your application (e.g. in case of a crash), even if you didn't explicitly have QML debugging switched on.
If you want to give Qt Creator 3.1 beta a try, you find the opensource version on the Qt Project download page, and Enterprise Customers find their package in the Qt Enterprise Customer Portal. Please post issues in our bug tracker. You also can find us on IRC on #qt-creator on irc.freenode.net, and on the Qt Creator mailing list.
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.
Yeah, stl containers and iterators finally work. Good stuff
@veio: Should have worked all the time, except that for 3.0.x it was tried (and failed) to import GDB's own pretty printers. Turned out that this was less than perfect, and the default for the setting (Tools->Options->Debugger, GDB, Load system GDB pretty printers by default) is now "off" again.
I meant the autocompletion :) The pretty printers in the debugger worked
I think the new deployment method seems like a very good idea, especially because of the earlier issue with load times on mobile platforms. On my Android tablet, the old deployment method caused an application with thirteen QML files to use about a minute just to load. With a resource file, it takes about 2 seconds. Keeping this load time to a minimum is also important for newcomers, and as long as it is as easy as it was to add new QML files in the IDE, I think many won't even notice the deployment has changed.
The only thing I would point out in the current beta is that the Projects tree-view should show the folders of the files in Resources as their own trees. Otherwise it is a bit to easy to create new QML files in the root folder by right clicking > "Add New...", and thus away from the scope of other QML files in the qml folder. Additionally, it seems like the code model is no longer refreshed when new files are added.
Can't find a way to set compiler flags for a selected compiler in the kit, so I don't have to set them on per project basis. Can it be done?
My question is whether latest gdb from Mac-ports is supported?
Thank you.
@Robert: Only LLDB is "officially" supported. There is nothing stopping you from trying to use GDB. It is reported to work for some cases, it does not work for others.
Where do I get a gdb-python for Windows that would be compatible with Qt Creator? I have MinGW 2013-10-04 (the latest) and installed the "mingw32-gdb-python" package from it, but Qt Creator seems unable to recognize gdb-python27.exe as a debugger.
Previously, Qt Creator came bundled with a GDB debugger, which made things easier to setup. Now I am not sure how we're supposed to proceed other than to compile gdb from source, is that really what we're expected to do?
Rather than adding new features, can we please ensure existing features are fixed first !?
For example
https://bugreports.qt-proje...
I was hoping that Clang code model will provide proper support for designated initializers in C. Unfortunately I was wrong. :(
Great work! I feel like many of the code model parsing issues I was having are fixed.
Also, I love the clang-format integration.
I would love the ability to diff with perforce in qtcreator and to color code changed lines in the margin. But that's just a feature request.
Love that you guys keep making the best c++ IDE better...
Good news. I see the new ClangCodeModel plugin is much faster than before, it could be used in daily work now.
Clang integration still has an annoying issue: https://bugreports.qt-proje...
Also clang precompiled header feature is not working at all.
The Clang code model is an excellent addition! (I was somewhat skeptical if it would ever make an appearance on Windows, but now it indeed has appeared! :) )
Hopefully the slowness and quirks can be improved at some point in the Clang code model, but this is a really nice first public start for this.
Nice one, great job again guys!
i like the wizard renewal for QtQuick applications as it now uses the QQmlApplicationEngine.
However, choosing the resource file by default might harden things for newcomers a bit, as you need to remember to copy all qml, js files and images into the qrc file. Plus, re-running the application if you just change QML code doesnt work without a re-compile any more if the qml files are put into a resource file.
So this seems like more disadvantages than before, where you had the boilerplate platform code for loading the qml on different platforms but these were "hidden" in a custom class and .pri subproject anyway.
>> re-running the application if you just change QML code doesnt work without a re-compile any more if the qml files are put into a resource file.
This is intermittent for me. Sometimes it works sometimes it doesn't. My solution has been to do an #ifdef QT_DEBUG, load QML from the filesystem, else load from resources.
The huge benefit of loading QML from resources is performance. Especially on mobile, loading QML from the filesystem is hideously slow.
Certainly the new approach has its own advantages and disadvantages. Some can be partially mended by support in Qt Creator (e.g. new file wizards could add these files to qrc). Regarding 'recompile': It needs to compile the qrc, and re-link. That puts changing a qml file to a similar level as changing a .cpp file. On the other hand, deployment gets way easier by using qrc, and the custom class & .pri file was a pita in many ways: Deployment was error prone, and we needed a complex and error prone way of updating these template files when we found and fixed bugs in them. Which also meant that you were basically stuck with what we gave you, since changing it was not advisable.
I think the new deployment method seems like a very good idea, especially because of the earlier issue with load times on mobile platforms. On my Android tablet, the old deployment method caused an application with thirteen QML files to use about a minute just to load. With a resource file, it takes about 2 seconds. Keeping this load time to a minimum is also important for newcomers, and as long as it is as easy as it was to add new QML files in the IDE, I think many won't even notice the deployment has changed.
The only thing I would point out in the current beta is that the Projects tree-view should show the folders of the files in Resources as their own trees. Otherwise it is a bit to easy to create new QML files in the root folder by right clicking > "Add New...", and thus away from the scope of other QML files in the qml folder. Additionally, it seems like the code model is no longer refreshed when new files are added.
@Christian: regarding the requirement to add each file, there is an obscure feature in .qrc/rcc which allows to include a complete directory.
Just do:
<RCC> <qresource> <file>parentfolder/contentfolder</file> </qresource> </RCC>...and it will include the contents of "contentfolder", but not recursively, just flat. Not sure if the new .qrc features in Qt Creator support it (I need to check that later).
Also, if you add a new file via wizard in Qt Creator by right clicking a resource file in the project tree, the new file will automatically be inserted in the .qrc. Of course that only helps with qml or js. Images or sounds still neeed to be added explicitly.
So yes, it is still a bit quirky and the convenience for the developer is a bit lower than it was before, but we belive that the end user of the app will benefit (speed on Android). And we will also try to make the developer happier in the upcoming versions. Feedback like yours points us into the right direction.
@Eike & @aportale
I fully agree deployment to mobiles strongly benefits by putting the files to the resources, this is definitely a good step forward!
However, for desktop the re-running feature speeds up startup times, esp. if you change images in your projects regularly. Also you do not need to explicitly add all files but just put them into the same folder, as they dont get compiled into resources that way.
So I think the best would be a combination of the 2:
For mobile using qrc files and on desktop using deploymentfolders as it was before. Or provide a wizard that allows this combination and use the new qrc-only approach by default to make it easier for newcomers.. Just my 5 cents. ;)