News

Port to Windows Runtime kick-started

With Windows 8, Microsoft introduced a new platform, the Windows Runtime. On the desktop, the operating system provides 2 modes:

Classic mode: This mode shows the familiar Windows desktop known from Windows 7 (with the exception of the start menu), in which traditional applications using the Win32 API run. No modifications are required for Qt 4 or Qt 5-based applications to run in this mode.

Modern UI (formerly known as Metro mode): This is a new type of user interface intended for tablet and phone UIs on which Windows Store Apps run. These applications use a new API called  Windows Runtime, which is based on the Component Object Model (COM). A similar API exists on Windows Phone 8.

Research work on how to port Qt 5 to use Windows Runtime was started by Andrew Knight from Digia and is visible in the winrt branch of the qtbase repository. Recently, further contributions by Kamil Trzciński were added to it (check out his blog). Now, with Qt 5.0 out of the door, we would like to kick off this platform port. This completes our cross-platform offering in addition to the ports for the widely used Android and iOS platforms.

We plan to continue development in this branch, aiming for as complete as possible port. Technical details can be found at here.

The first milestone is to get simple raster windows to be drawn on the screen. Later, we will investigate porting ANGLE to get OpenGL ES 2.0 suppport required for QML2.

Similar to the android branch, the idea is not to merge the branch, but later look at it and apply its changes to the dev branch.

To play with the branch, create an environment with a x86 MSVC2012 compiler and configure Qt with:

configure -nomake examples -nomake tests -developer-build -opensource -confirm-license -xplatform winrt-x86-msvc2012

We are also planning on creating a Qt Creator plugin to support deployment. Andrew Knight has already started on it in the winrt branch of his Qt Creator repository.

The work has still the “Research” status, so, we are not able to give any release dates yet. We aim to have something ready for the 5.2 release. However, since the development happens in the public winrt branch, the current state is always visible and it is easy to participate.

Contributions and help are warmly welcome.

Happy Hacking!

Qt 5.0.1 Released

It’s been six weeks since we published the Qt 5.0.0 release and we are now introducing Qt 5.0.1 – the first patch release. Qt 5.0.0 release has been well received and we have seen a great amount of interest towards it.

With over 400 improvements compared to Qt 5.0.0 the Qt 5.0.1 is a great next step for the Qt 5 series. As a patch release it does not introduce new functionality, just error corrections and improvements. In addition to these, it also adds MinGW 4.7 pre-built binary installer, which has been highly requested. MinGW is the first but not the last new pre-built binary installer which we are going to bring along on later Qt 5.0.x releases.

For detailed list of changes in Qt 5.0.1, please have a look into the changes file included to each module – or check the three most important ones: qtbaseqtdeclarative and qtmultimedia.

As always, Qt 5.0.1 maintains both forward and backward source compatibility with Qt 5.0.0. However, to fix a bug we detected after the Qt 5.0.0 release, this release has a limited binary compatibility break related to multimedia functionality (please see details from here). We therefore recommend all users to recompile their applications that provided QtMultimedia plugins or dealt with them directly. This is an exceptional case: binary compatibility will be kept for further releases.

As with every release, also this one has a few issues left that we know about. We are continuously ironing out the glitches and improving quality with every new release. If you encounter a problem, please check the known issues page first, where you can find solutions and workarounds for common problems. If you find any other bug in Qt 5, please help us to improve the product in future releases by reporting it to bugreports.qt-project.org, or contact us via our Customer Portal if you have a commercial license.

Qt 5.0.1 is now tagged in the Qt Project repository. The source packages and installers for Qt 5.0.1 are available for download at qt-project.org/downloads for open-source users, as well as via the Customer Portal for commercial licensees.

Qt – Gearing up for the Future

Now, a week after Qt Developer Days Berlin where Digia presented its strategy for Qt moving forward, I wanted to take a moment to recap a bit of what I presented.

When Digia announced the Qt acquisition three months ago we asked everyone to revisit their perception of Qt. Digia’s targeted R&D investments will bring back focus on Qt’s desktop and embedded platform support, while widening the support for mobile operating systems. During the whole acquisition process and now during the integration we have been updating our own vision. This is what we presented in Berlin last week.

It is clear that things will change as Digia will have different targets with Qt than what they were during Nokia times. We have been with Qt quite a long time and thus have good solid foundation to continue the investment. With more than 200 Qt experts in our organisation we will continue remarkable investments for the Qt technology. At the same time, Digia has been pioneering for over a decade with Qt on desktop, embedded and mobile systems having great experience in all key areas of Qt.

Qt is an established and well-recognised technology with hundreds of thousands of developers around the world within dozens of industries. Developing the technology further requires a solid common vision and value proposition – a clear high-level roadmap. Our Qt vision for 2017 includes several elements around the product and the ecosystem. We see these more as values than just elements in a Qt roadmap.

  • #1 in multi-platform support
  • #1 in developer experience
  • #1 in creating great user experiences
  • Dual licensing model
  • Strong value-generating ecosystem.
  • Open business architecture

This is our starting point for a discussion with the ecosystem. Digia will be one of the biggest investors around Qt with approximately 15 MEUR annual investments for R&D and ecosystem activities. We have set these simple vision elements in place to clarify how we are seeing the future of Qt.

Qt is an amazing technology, unmatched by any other solution for cross-platform application development. We see the multi-platform support as a key value proposition of Qt also in the future. Even though Qt has been developed according to the multi-support value during last years, there are still some gaps in platform support. We have already announced the support for iOS, Android but also for BlackBerry and also to some extend for Windows 8. The computer industry is changing rapidly, especially when it comes to user interfaces and user experience but also the market shares have been changing radically. Supporting the key operating systems is the only way to be successful with this promise and achieve the target of #1 in multi-platform support.

Developer experience has been a core value of Qt and it also will be in the future. Qt is developed by the developers for developers. We want to make developer’s lives easier, but this is also an element which requires more concrete actions to become a reality. Namely this is improving the whole contextual environment where developers are working including tools and documentation. This is something we are working on all the time and improvements are hopefully visible gradually in all new versions. Only such development can make us #1 in developer experience.

The requirements for software development have been changing. Networking real-time applications with fluid 60 fps animated user interfaces are here to stay. At the same time most of applications must be available in different form factors – desktop, tablet and mobile. Or they must perform with limited hardware capabilities in an embedded environment. Software developers are facing huge challenges and seeking for a solution to create winning user experience applications. Qt must win the mindshare as the most productive platform and #1 in creating great user experience. This must be a concrete offering in terms of intuitive APIs, easy to use tools and state-of-the-art framework with best of breed performance.

Additionally to these product-related value propositions we would like to emphasize a few items related to the ecosystem and the business environment. Qt is not only a product, but also very lively ecosystem furnishing both businesses and individual developers who have their own targets. Such an ecosystem requires a stable environment to develop and go forward. We strongly believe in the dual licensing model. Maintaining this model will be a foundation for the future success of Qt. Commercial licensing secures the future investments to R&D and the LGPL provides a larger user base and adoption of the technology. Combining the best of both worlds enables the widespread use of Qt.

Securing a stable business environment enables a strong value generating ecosystem. We want to enable the ecosystem to continue contributing to Qt. Additionally, we want to ensure that there are forums to enable the dialogue around the development of Qt. The open governance model and the Qt Project form one venue for everybody to get their needs heard. Additionally, we introduced the Digia Qt Partner Program offering a direct connection to the Digia Qt R&D and management. With this model we would like to offer various industry players a way contribute and steer the common investment.

As a new element in the Qt ecosystem we introduced the principle of open business architecture. Digia’s rationale to invest in Qt is commercial by nature. However, we believe that enabling more business opportunities for everybody via Qt will be beneficial not only for Digia but the entire ecosystem.  Open business architecture is a principle that defines the rules for equal playing ground where everybody is invited to participate. At this point, we see this as a principle, but later on we hopefully are able to develop the whole business architecture forward in such way – and enable more business for everybody.

As you may have heard, Qt5 is coming soon; hopefully in December. It will bring us more performance, better tools and ease of deployment. Next year – 2013 – will bring us more concrete deliverables related to all the values I mentioned.  We have already announced some of them. Lars presented many of these in his roadmap keynote presentation. We hope to be able to share his presentation soon. Things will change. This is the new Qt world from our perspective. I hope the whole ecosystem will join us on the Qt ride.

Have a look at our demos presented in Berlin last week – Qt on Android, iOS, WinRT, VxWorks, Mac.

 

Qt 4.7.4 Release Bundle for Symbian News

Today we are making available the Qt 4.7.4 release bundle for all Symbian^3, Symbian Anna, and Symbian Belle devices. The Qt SDK 1.1.4 update has the necessary Symbian Anna and Belle build targets available allowing application development for Qt 4.7.4. Nokia Store deployments are also possible.

This is a big release for Qt developers. In this blog post I’d like to present an overview of the current Qt deployment situation on Symbian devices. The later part highlights the most important changes we have in the Qt 4.7.4 release bundle from the Symbian perspective. Those of you who know the Qt Symbian deployment history can skip directly to Qt 4.7.4 section.

Qt deployment on Symbian devices

The first officially supported Qt release for Symbian devices was Qt 4.6.3. It was released together with Qt SDK in June 2010. Following this, applications created with this SDK could be deployed to Nokia Store (or Ovi Store as it was known then). Then this year in May 2011 Qt 4.7.3 for Symbian with Qt Quick was made available in the Qt SDK 1.1, and Qt Quick applications could be deployed to Nokia Store.

Qt was not available right away as pre-installed in any Symbian devices when Qt 4.6 was made available for Symbian. In fall 2010 the Nokia N8 was released and it was the first Symbian device with pre-installed Qt. Then in the middle of 2011 Symbian Anna was made available with the Qt 4.7 -based bundle with Qt Mobility 1.1. Now the latest Symbian Anna devices have out-of-the-box support for Qt Quick.

For older S60 3rd and 5th Edition devices Qt is an add-on component requiring initial download of Qt libraries on the first Qt application installation. A special deployment mechanism called Smart Installer is used to deploy Qt to devices such as these that do not have Qt as pre-installed or in the firmware.

When the user downloads and installs a Qt application, Smart Installer checks package dependencies and installs Qt and other support modules when needed. Modules are also upgraded to newer versions when necessary. Normally this happens when the user downloads an application from Nokia Store.

Smart Installer is the main deployment channel for the Qt release bundle to S60 3rd and 5th Edition devices. Smart Installer also updates Symbian^3 devices’ pre-installed Qt 4.6.3-based bundle (that resides on the C: drive), to the Qt 4.7.3-based bundle. Furthermore, an important reason for Smart Installer deployments is the fact that Symbian^3 devices do not have the pre-installed Qt Mobility module. Hence, before the application is installed on Symbian^3, often at least the Qt Mobility module is deployed unless it is already deployed by earlier application installations. Developers have always been advised to take into account this additional download need because it increases the application’s delivery size.

In July 2011 Qt Quick Components 1.0 for Symbian was released with Smart Installer deployments for Symbian Anna devices.

Today’s Qt 4.7.4 bundle is the next big Qt release with many improvements for Symbian OS. This release is shipping already in the new Symbian Belle devices, like Nokia 700 and Nokia 701, as part of the device firmware. Now we are making it available also to devices with Symbian Anna (and Symbian^3) through Smart Installer deployments and we are also bringing finalized Qt SDK support.

Qt 4.7.4 release bundle for Symbian

The Qt 4.7.4 release bundle contains

It is supported in Symbian Anna (and Symbian^3) devices onwards. Most benefits mentioned in the Qt 4.7.4 release post by Jarmo are valid for Symbian, too. In general, this release has a huge amount of stability, performance and functionality improvements for Symbian. Many of the changes also make Qt better integrated to the Symbian operating system services.

In Qt graphics system for Symbian there are big changes in how graphics resources are managed in the default OpenVG graphics system used by Qt applications. We are also introducing the opt-in OpenGL ES based graphics system to wider use with better resource management as part of Qt 4.7.4. Both of these changes improve the use of scarce GPU memory and have better graphics memory releasing schemes when applications are moved to background. We have also better integration to Symbian OS transition animations. This means that when stopping and starting Qt applications there are smoother animations that are also better aligned with the same effects presented with Symbian OS Avkon applications.

Regarding the user interface, Qt Quick Components 1.1 and Qt Quick 1.1 modules provide the biggest improvements. There’s another post by Sami detailing changes available for components. For both we have also changes explained in the Qt Quick – What’s New and Qt Quick Components – What’s New documents. The use of Qt Quick Components allows application to achieve the new Symbian UI Design Guidelines. This means that Qt applications match and are consistent with the native applications on Symbian Belle devices.

In the “core” of Qt there are plenty of minor improvements and bug fixes to UI features. Often these fixes will improve all style of Qt applications regardless of the UI technology: QWidgets and graphics view based and QML UIs too. For example, on physical keyboard devices Nokia E7 and Nokia E6, text editing key accelerometers (ctrl+c/ctrl+v) work now out-of-the-box in editors without any need for an application to implement such copy/paste functionality.

Split-view keyboard on the bottom, editor using it on the top.

Perhaps the most welcomed UI feature of Qt 4.7.4 is the integration of Qt text input system to the Symbian partial screen text input component also known as split-view input. The split-view input is a new virtual keyboard in Symbian Anna where it is used in many native Avkon applications. It allows application content to be visible above the split-view keyboard. This is in contrast to the earlier full screen input that didn’t allow application content to be visible during text input. In Qt 4.7.4, the split-view is now integrated into all editor widgets in graphics-viewbased UIs including Qt Quick/QML editors. By default this feature is disabled because the split-view input needs application awareness due to layout change in the visual area of the application when the new keyboard is opened. It is enabled by setting the application attribute Qt::AA_S60DisablePartialScreenInputMode to false. Qt Quick Components 1.1 uses this split-view feature too and it will be available when application starts to use the new import com.nokia.symbian 1.1of the components. The import 1.0 still uses the full screen input. So in other words, Qt Quick 1.1 or plain-Qt applications turn it on with the application attribute but Qt Quick Components 1.1 using applications with the new 1.1 components import.

Belle Status Panel

Symbian Belle UI: new iconic softkeys on the bottom, status bar on the top and status panel half open on screen.

Qt 4.7.4 also enables the new Symbian Belle features like the new iconic toolbar support: QActions can have SVG images and the new Symbian OS toolbar icon set can be accessed via QStyle API. As mentioned, Qt Quick Components is provided as an easy way to align the application UI to the new UI style. For example, using StatusBar from the Qt Quick Components allows an application to automatically provide access to the new Belle UI’s status panel feature that is opened by doing touch swipe down gesture on top of the status bar.

Qt Quick with Qt Quick Components is the recommended UI solution for Symbian applications. In fact we have documented that old QtGui module widgets on Symbian are deprecated and developers should use Qt Quick Components instead in new application projects. In that document we also have a list of widgets that should never be used from QtGui module on Symbian because they have never been supported or worked properly.

The last new UI feature worth mentioning is the TV-out support in Qt 4.7.4. When using TV-out, this feature makes possible to use TV display as an independent screen rather than just clone of the device screen. Applications can provide different control view on device screen and a presentation mode with larger resolution on the TV-out display. It works with devices with either analog 3.5mm composite video output or HDMI output. 
By default, in Symbian devices the content shown in TV-out is a clone of the device screen. From now on, however, parenting a widget to QDesktopWidget::screen(1) and calling show() will turn off cloning and have different content shown instead. The screenCount member function and the screenCountChanged signal can be used 
to detect the availability of the secondary display, just like on other platforms.

NFC in Nokia 603

The new Nokia 603 is NFC enabled

Together with Qt 4.7.4, the Qt Mobility module is updated to version 1.2. The main new features are the two new local communications APIs: NFC (Near Field Communication) and Bluetooth. Bluetooth is a basic feature in all Symbian devices but NFC is a new hardware feature only in latest device models. The NFC hardware support is however becoming rapidly available. All new Symbian devices – Nokia 603, Nokia 700 and Nokia 701 – are NFC-enabled. From the earlier Symbian devices only Nokia C7 is NFC enabled. To find out more on the NFC development check the Introduction to NFC guide from Nokia Developer and the general NFC page.

There are other minor improvements and lots of bug fixes in Qt Mobility as well. For example, QAudioOutput class has now a proper support for pausing in Symbian. Earlier, calling suspend via API was emulated by using stop underneath the implementation that caused delays on doing resume later. Video outputs are rendered now with black when nothing is rendered. This improves UIs when QML video and camera elements are used.

The QML ShaderEffectItem is also available in this bundle. Kim showcased it very nicely in his earlier post.

There has been lot of effort made in Qt 4.7.4 to improve the memory management. Applications using Qt 4.7.4 libraries normally consume less RAM than using earlier Qt libraries. Symbian platform uses predefined sizes for stacks and heaps. However, application developers need to be very careful on memory usage. If an application exceeds stack or heap limits, it may crash or fail to complete its task. Crashes that seem to have no reason can often be traced back to insufficient stack and/or heap sizes. Application developers should use reasonable values for maximum heap size. Either too small or too big value could cause the application’s failure. Other than RAM, there is very limited video/graphic memory of 32 MB especially in Symbian^3 and Symbian Anna devices (the new devices that shipped with Symbian Belle have four times larger GPU memory of 128 MB). It’s important that applications using large graphics resources follow graphic memory handling guidelines.

See also our Qt 4.7.4 release application compatibility notes from Qt Developer Network.

The rest of this post talks of non-feature aspects of this release: what kind of build targets we have in Qt SDK and how the Symbian support is aligned with Qt found in Nokia N9. But first, I’ll explain one internal change that is good to know.
Continue reading

Launch of the Qt Project imminent…but not on Monday

Followers of the Qt Project will know we announced October 17 as our target launch date for the project.

Unfortunately this date is no longer achievable, and we will be delayed by what we expect will be three to four days. A huge amount of hard work has been done, and we are down to a few very important final steps that we are taking a great deal of care with.

In addition, the administrative processes surrounding the creation of the Qt Project hosting entity are very near completion, which we’re glad about :)

We appreciate everyone’s support and patience, and look forward to announcing the official start of the Qt Project very soon.

Regards
Lars

Qt Contributors' Summit – Last Minute Updates

We are neck deep in the final preparations for the Qt Contributors’ Summit and we have a few points to share with you:

First off, thanks to everyone who has listed their topics for our event. It is looking like we are going to get a lot of really great discussions going and we can’t wait to see the sparks fly. A full list can be found on the Qt Developer Network.

Point two: we are full. Really full. I will start off by saying thank you to all who registered before the deadline closed so that we could adequately plan rooms, seating, food, etc. But knowing you folks well enough there would be a number of people we would have to let in after registration has closed due to some arm twisting and eyelash fluttering, etc.

However even with a healthy level of padding, we have been overwhelmed with last-minute requests and are now at the very limit of our capacity.

Why am I saying this? Because we suspect that there might be a few of you who show up on our door with puppy dog eyes looking to slip in at the last minute. I am deeply sorry to say that even the sweetest “puleeese?” won’t help. For the sake of the others attending, we simply can’t let any more people in at this stage.

Queue

Also, to make sure there are no sad, disappointed faces at the show: As hard as we tried — and trust us, we tried darned hard — to actually launch open governance at the summit and open the repositories, we have to hang our heads and say we just weren’t able to do it.

Its a complex thing to do, and we want to make sure we do this properly so that we don’t have any painful repercussions down the road. In short, we aren’t going open governance at the show, however we remain completely committed to it and we hope to solve this shortly.

For those that have a special stash of awesome code squirreled away that was going to be unleashed upon us at the summit, fear not! Our existing contribution system is still up and running and we have dedicated the resources necessary to ensure these contributions are quickly reviewed and incorporated into Qt, per the usual process.

Ok, I think thats it. Looking forward to seeing you all in Berlin. Lets make this a great summit!

Qt Contributors' Summit – update wk 22

Now that I am back from the MeeGo conference in San Fransisco, it feels even shorter: the summit is approaching fast – only 3 more weeks to go! Time to reveal some details on the current state of affairs.

After closing registration, I now have some solid numbers. More than 250 attendees have registered leaving us at an almost 50/50 of Nokia employees and non-Nokia folks. Furthermore, we were able to sponsor trips to Berlin and/or related accommodation for 26 community members.

Everyone who has registered online should have received their confirmation email by now. In case you didn’t, you probably didn’t make it onto my list for some (probably browser related) reason. Send me an email and I will fix it.

I finished the timeline for the schedule (which you can find here), the grid is ready to be (partly) filled in for those attending. Hanne has coordinated the training sessions which will be recorded and published afterwards for later reference. For late night coding and/or chatting we will have a hacker lounge open during the night with free drinks, plenty of power outlets, wifi and comfy sofas and chairs.

We have the keynotes lined up and for the social event on Thursday night I could book a special act: our very own infamous Trollband!

Now the ball is mostly in the attendee’s court to join discussions, document the outcome and generally socialize among fellow Qt’ies. I’m starting to look forward to the event. :)

C++0x in Qt

While many are so enthusiastic about QML and javascript technology, a few of us still code in C++ ;-) . C++ is about to get an upgrade: C++11 (formely known as C++0x). The final draft was aproved last march in the C++ standard commitee, and the final specification is expected to be published this summer. If you don’t know it yet, I invite you to read specialized pages, such as Wikipedia or C++0x FAQ

One of the goals of C++0x is supposed to make the language easier. Which is hardly possible since it only adds more stuff to learn, but with the hope that the “mosty used” subset of C++ should be easier and more intuitive.

The good news is that you do not need to wait to use it. You can start today. The compiler you use probably already supports some of C++0x: GCC or MSVC 2010

While you can already use C++0x with older Qt version such as Qt 4.7, Qt 4.8 will come with more support for some of the new C++0x constructs:

New Macros

Some macros are defined if the compiler supports the new features

Q_COMPILER_RVALUE_REFS
Q_COMPILER_DECLTYPE
Q_COMPILER_VARIADIC_TEMPLATES
Q_COMPILER_AUTO_TYPE
Q_COMPILER_EXTERN_TEMPLATES
Q_COMPILER_DEFAULT_DELETE_MEMBERS
Q_COMPILER_CLASS_ENUM
Q_COMPILER_INITIALIZER_LISTS
Q_COMPILER_LAMBDA
Q_COMPILER_UNICODE_STRINGS

Initializer lists
Qt 4.8 adds new constructors to QVector, QList, and QStringList which enable you to initialize them using the bracket initializer.
You can now do

QVector<int> testsData { 1, 2, 10, 42, 50, 123  };
QStringList options = { QLatin1String("foo"), QLatin1String("bar")  };

which initializes the containers with those element.

Rvalues references and move semantics

Most of Qt classes are implicitly shared, meaning it is efficient to copy them if you do not modify them (copy on write). This is not the case for std::vector, where each copy implies copying all the data.
So if you have code like

std::vector<int> m_foo;
...
m_foo = getVector();

The getVector may construct a new std::vector, and return it as a temporary object, then the std::vector::operator= will delete the old content of m_foo, then copy all the data from the temporary vector to m_foo. At the end of the statement, the temporary vector will be destroyed, and its destructor will delete its data. It would be way more efficient if instead, the operator= would exchange m_foo data with the temporary vector’s data. That way, m_foo’s old data would be deleted when the temporary is destroyed, and we would not create a useless copy. This is what the move semantics in C++0x is, and it is achieved through rvalue references.

Even if copying an implicitly shared class is cheap, it does not come for free, we still have to increase and decrease the reference count, and the calls to the operator= cannot be inlined, since it accesses the private data. (We can’t inline that to ease binary compatibility).
So now, look at the Qt 4.8′s QImage move operator:

#ifdef Q_COMPILER_RVALUE_REFS
    inline QImage &operator=(QImage &&other)
    { qSwap(d, other.d); return *this; }
#endif

We just swap the internal data of the two images, this is a very cheap operation compared to the normal operation which requires a function call. We added this to most of the implicitly shared classes in Qt.
Since the operator= of all our containers is used a lot with temporaries, it may give small improvements to the speed of Qt, which might be a reason to compile Qt with C++0x support (see below).

Range-based for-loop

Qt had already a very convenient foreach, You can also find it in some other library, such as Boost.
The Qt foreach works with complicated macro, But C++0x goes further and make this construct part of the language.
So, instead of writing

foreach(const QString &option, optionList) { ... }

you can write

for (const QString &option : optionList) { ... }

There is a slight difference between the two: Qt does a copy of the container before iterating.
This is cheap for Qt container as they use implicit sharing, but is expensive with standard containers that do a deep copy of the whole content.
The C++0x range-based for does not copy, which means the behaviour is undefined if you add or remove items from the container as you iterate.
The new for will call the begin() and end() functions which are going to make a copy of the Qt container if it is shared and non const. Hence, it is better to pass const containers.

template<class T> const T &const_(const T &t) { return t; }
for(auto it : const_(vector)) { ... }

Lambda

We tested lambda with some of the QtConcurrent functions.
We tested it with QtConcurrent::run and QtConcurrent::map
But it does not work yet for QtConcurrent::mapped, we may fix that in the future.

So the scale example of the Qtconcurrent::map documentation could be rewriten like that

  QList<QImage> images = ...
  QFuture<void> future = QtConcurrent::map(images, [](QImage &image) {
            image = image.scaled(100,100);
        });

I am also researching using lambda in signal/slots connections, but that would be for Qt5.

Unicode Strings

We do not yet support the new string types. But that might come later.

Go and use it!

If you are using MSVC 2010, there is nothing to do, you can already use some feature such as the lambdas or the rvalue references.

If you are using gcc, you need to pass the flag -std=c++0x.
You can do that in your qmake project file like this:

QMAKE_CXXFLAGS += -std=c++0x

If you want to compile Qt using C++0x you can do

CXXFLAGS="-std=c++0x" ./configure

Qt compiled with C++0x is binary compatible with the good old C++. And you do not need to compile Qt with C++0x to write your own application using C++0x,

Technology Preview of Qt 4.8 now available for testing and feedback.

I am very happy to announce the release of a Technology Preview of Qt 4.8 to the community for testing and feedback.

Qt 4.8 will be a release containing a lot of quality and performance improvements that were carried out during the last 12 months, such as File System performance improvements. It also includes the Qt Platform Abstraction (Lighthouse) feature, which enables easier porting of Qt into new graphics systems for third parties. Today’s Technology Preview is released to get your feedback, comments and improvement ideas.

Packages – Qt 4.8 Technology Preview
The Qt 4.8 Tech Preview packages available today have been tested with Windows 7, Mac OS 10.6, Linux and Symbian^3.

Supported platforms for Qt 4.8
Targets for Qt 4.8 will be announced in due course. As a reminder and a guide, the supported platforms for Qt 4.7 are available here http://doc.qt.nokia.com/4.7-snapshot/supported-platforms.html

Deprecated items list in Qt 4.8
As announced recently, we will deprecate a list of items in the Qt 4.8 release. This list can be found in http://labs.qt.nokia.com/2011/05/12/qt-modules-maturity-level-the-list/

Schedules
We are aiming to release Qt 4.8 beta in next few weeks and the final release candidate in the second half of 2011. These are available through the SDK only.

Thanks
We would like to thank all developers, contributors, the documentation integration and testing teams in Qt releasing for making this happen!

The Qt 4.8 Tech Preview is available now at
http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.8.0-tp.zip
and
http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.8.0-tp.tar.gz

We are looking forward your contributions, comments and suggestions on the Qt 4.8 Tech Preview. Please post your bug reports in http://bugreports.qt.nokia.com.

Best
Pia, on behalf of Qt 4.8 Program Team

Qt Modules' Maturity Level: The list

Last week, I blogged about the framework of levels we’re proposing to use for Qt in the context of Open Governance and future development. I said then that we had also taken the time to look into what code we have in Qt and decide what level it should be in. Today, I’d like to share the list that was the result of that work.

First of all, please understand that this applies to future releases of Qt, most importantly Qt 4.8 and 5.0. Since we never add or remove features to existing and current release series, the framework doesn’t apply there, except as in what kind of bugfixes we might be accepting. For example, a bugfix for a corner case could potentially introduce regressions, so the community needs to take into account the quality level of the code and the ability to execute regression and release testing before accepting said commits. Moreover, it’s also possible to obtain differentiated support for past releases from other companies, especially from Digia. This is however outside the scope Open Governance.

Second, the list below contains only what is not in states Active or Maintained. We felt that the most important thing to do right now was to be really honest about what we (Nokia) are working on and what we’re not working on. This is especially important for people reporting bugs, since it is unlikely that we will fix low-priority issues in subsystems that are in the Done state or lower. What’s not on the list below is then under the state “Active” or “Maintained”, like for example QtDBus. Also note that this list focuses on Qt only, which is the older codebase, containing more legacy.

This first publishing of the list is, by necessity of a blog, a static list. In reality, when Open Governance and Qt 5 work kick in, this list will be very much dynamic, so I’ll be importing it into the Qt Developer Network to be edited and kept up-to-date. So I want to be very clear that the list can change and modules may go up or down in the Level scale. The only things that should not happen are: a) sacrifice quality and b) take Qt in the wrong direction (backwards). As an example of the latter point, functionality that gets Removed from Qt should not be brought back: we don’t want to support IRIX, the non-Unicode Windows versions or Microsoft Visual Studio 6.0.

Finally, let me remind you that Done is not Deprecated! Done really means “stability and zero regressions are the most important things, so we are not adding features and we are not working on improving performance, but it’s fine to use this code”.

The list

Modules

  • ActiveQt
    Overall module state: Done
    New Maintainer Required
  • Phonon
    Overall module state: Done inside Qt, Maintained outside of Qt
    Reasoning: QtMultimediaKit recommended instead; development of Phonon continues and is maintained outside of Qt, by the KDE community.
  • qmake
    Overall module state: Done
    Reasoning: stable code, we don’t recommend bringing it up in the level list. Research into a future, more modern buildsystem has started. 

    • XCode integration
      State: Deprecated
      New Maintainer Required.
  • Qt Designer
    State: Done
    Reasoning: Qt Quick is recommended for developing UIs from now on, so the new Qt Quick Designer should take over the capabilities of the classic Qt Designer.
  • Qt3Support
    Overall module state: Deprecated
    Reasoning: Qt3Support was provided as a porting layer from Qt 3, so the recommendation is to finish the port. Qt3Support will be Removed in Qt 5.
  • QtCore
    Overall module state: Active/Maintained 

    • QFileSystemWatcher
      State: Deprecated
      Reasoning: flawed design, a replacement is required. We’re open for ideas in that area.
    • Abstract file engines
      State: Deprecated
      Reasoning: flawed design, this is the wrong level to provide a virtual filesystem, so we don’t recommend taking this over. In Qt 5, this functionality will be Removed.
  • QtDeclarative
    Overall module state: Active/Maintained 

    • Graphics view support (i.e., QML 1.x)
      State: Done
      Reasoning: QML Scene Graph-based QML 2 is recommended and will become available in Qt 5.
  • QtGui
    Overall module state: Active/Maintained
    More information about reorganisation of this module, see the Qt 5 blog

    • XLFD support for the font system
      State: Deprecated
      Reasoning: this is obsolete functionality in X11 as modern systems use client-side fonts; doesn’t affect other platforms.
    • Graphics Effects
      State: Deprecated
      Reasoning: flawed design, we don’t recommend taking maintainership of this code.
    • Graphics View
      State: Done
      Reasoning: stable code for which stability and reduced risk of regressions is more important; we don’t plan on adding more features.
    • Implicit native child widget
      State: Done
      Reasoning: flawed design, we don’t recommend taking maintainership of this code.
      Note: widgets with explicit native window handles, like Direct3D view, will still be supported.
    • Printing support
      State: Done
      New maintainer required. 

      • Postscript support – Deprecated
        Reasoning: obsolete support, PDF is enough nowadays.
    • QPainter
      State: Done
      Reasoning: stable code for which stability and reduced risk of regressions is more important; we don’t recommend bringing the maintainership level up. 

      • Raster and OpenGL (ES) 2 engines – Maintained.
      • Other engines – Done and New Maintainer required.
    • QPainterPath’s “set” operations
      State: Deprecated
      Reasoning: flawed design, we don’t recommend taking maintainership of this code.
    • QPicture
      State: Deprecated
      New maintainer required.
    • QSound
      State: Deprecated
      Reasoning: better solution available in QtMultimediaKit.
    • Styles
      State: Done
      Reasoning: stable code for which stability is extremely important, so we don’t recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs and, with it, Qt Quick-based theming and style possibilities. 

      • Motif and CDE styles – Deprecated
        Reasoning: obsolete.
    • Stylesheets
      State: Done
      Reasoning: stable code for which stability is extremely important, so we don’t recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs and, with it, Qt Quick-based theming and style possibilities.
    • Widget classes like QPushButton, QLineEdit, etc.
      State: Done
      Reasoning: stable code for which stability and reduced risk of regressions are important, so we don’t recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs, with Qt Quick Components.
    • XIM support
      State: Deprecated
      Reasoning: flawed design, we don’t recommend taking up maintainership of this code.
  • QtNetwork
    Overall module state: Active/Maintained 

    • QHttp and QFtp
      State: Deprecated
      Reasoning: replaced by QNetworkAccessManager; we welcome research supporting the filesystem functionality of FTP that is not currently present in QNetworkAccessManager. In Qt 5, these classes will be Removed.
  • QtScript
    Overall module state: Active/Maintained 

    • QScriptEngineAgent and related classes
      State: Deprecated
      Reasoning: flawed design, being replaced by a better design.
  • QtSql
    Overall module state: Done
    New maintainer required.
  • QtSvg
    Overall module state: Deprecated
    New maintainer required
    Reasoning: SVG Full (as opposed to SVG Tiny) functionality available in QtWebKit, which should be used instead; we welcome research for a replacement for the SVG-generating code.
  • QtWebKit
    Overall module state: Active/Maintained 

    • QWebView and QGraphicsWebView
      State: Done
      Reasoning: moved to a separate library in Qt 5, the main entry point for web views will be the Qt Quick-based “webview” component.
  • QtXml
    Overall module state: Done
    Reasoning: QXmlStreamReader and QXmlStreamWriter are recommended instead and are located in the QtCore module.
  • QtXmlPatterns
    Overall module state: Done
    New maintainer required.

Functionality

  • Carbon support in Mac OS X
    State: Done
    Reasoning: Cocoa support is available and Carbon cannot be used to create 64-bit applications. We’d like eventually to Deprecate and even Remove this functionality during the Qt 5 lifecycle, as this code is currently a maintenance burden (like Windows non-Unicode was).
  • HP-UX, AIX and Solaris support
    State: Done
    New maintainer required.
  • Old Qt solutions archive
    State: Deprecated
    Reasoning: old code, not maintained anymore.
  • Bearer Management inside Qt Mobility
    State: Deprecated for now, will probably be Removed in Qt 5.
    Reasoning: the copy of the code maintained in QtNetwork is the recommended interface.
  • Qt Multimedia inside Qt
    State: for 4.8 it is Deprecated, in Qt 5 it is replaced by the Qt MultimediaKit copy with the modularisation of Qt.
  • Phonon copy inside Qt
    State: Done
    Reasoning: a separate release of Phonon, with its own version numbers, is available and can be used instead; the copy inside Qt will not be updated further.
  • Qt WebKit copy inside Qt
    State: Deprecated
    Reasoning: a separate QtWebKit release, with its own version numbers, is available and should be used instead with Qt 4.7 and 4.8, for those looking for updates. In Qt 5, the separate release is reintegrated through the Qt modularisation.
  • QWS (a.k.a. the current Qt for Embedded Linux)
    State: Done for Qt 4.8
    Reasoning: the new Lighthouse-based architecture is recommended for new features and new platforms.
  • Static builds of examples and demos
    State: Removed
    Reasoning: this is not maintained or checked and the Qt binary builds are always dynamic. Static builds aren’t required for reading the source code and learning Qt, they are never deployed to devices.
  • Static builds on Mac, Windows and Embedded Linux
    State: Done
  • Windows CE port
    State: Done
    New maintainer required.
  • WINSCW port
    State: Done
    Reasoning: old and buggy compiler, required only for Symbian simulator builds, should be replaced with a new technology once that is available.

Changing the list

As I said before, this list should live in the Qt Developer Network wiki, where it will be updated as the states change. So how do they change?

The state of a given functionality or module is the choice of the maintainer of that code, who is the ultimate responsible for the quality. So the decision on whether new features and the extent of what other kinds of changes should be accepted or not is also the responsibility of this person. Therefore, to change the state, you have to either convince the current maintainer or become a maintainer yourself.

In that light, we have been discussing with current contributors to Qt and asking them whether they would like to volunteer for maintainership of anything. Digia has already volunteered find someone to maintain the AIX and Solaris ports and KDAB has done the same for Windows CE. Becoming a maintainer for something inside Qt shouldn’t be too hard: it takes time and dedication, because it comes with a responsibility. (For that reason, we’d like people to prove that they can do it first, such as by maintaining a branch first)

More discussions on this should begin with Open Governance and the Qt contributors Summit.

The Qt Blog

Welcome to the new Qt blog! We have consolidated all the blog posts from the Qt Labs Blog with the posts from the Digia Qt Commercial blog. Our intention is to provide you with one area for all Qt development posts from our Qt experts.

As Qt enters a new era, we are working diligently to provide you with an ever-growing Qt Blog that includes projects, awesome ideas, tips and tricks and product info from our pool of very clever Qt developers.

This blog will be transforming as we move forward, so keep your eyes peeled for new developments.

Archives

Categories