Qt – Gearing up for the Future

Published Tuesday November 20th, 2012 | by

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.

 

Did you like this? Share it:
Bookmark and Share

Posted in Events, News, Qt, Qt Developer Days, Roadmap

53 comments to Qt – Gearing up for the Future

7 says:

“Only such development can make us #1 in developer experience” – I suggest to start by respecting the wish of over 2/3 of the community, active at Qt-project, expressed in this thread http://qt-project.org/forums/viewthread/16465/

QML and QtQuick are good tools, but as with every technology, they do have specific target of application, and QML simply doesn’t address a very important high margin market segment, albeit a narrow one.

BW says:

Independently of wether the question makes sense or not, the way it is formulated to infuence the voters makes this poll anyway lose all its credibility. Additionally, you should also think about the way users and developers want Qt to evolve in terms of priorities. Providing that the resources are great but limited, should Digia and Qt focus first on bringing a real multi-platform solution, improving developer tools, user experience or first extending Quick to support a C++ API? I guess that the answer is not that easy to answer.

I am personally confident that Qt development is going on the right direction, the roadmap clearly states that Qt will also focus on providing the best possible developer experience and I am pretty sure that all alternatives (such as *yours*) will be taken into account.

7 says:

I disagree, even thou the poll is formulated to overexponate the drawbacks of QML, I don’t think it influences the vote in what you allege is a manipulative manner. And it is not like people just blindly vote based on a single sentence without understanding the matter of the subject. Claiming there is no credibility to this result is, if anything, a big “in your face” insult to all those people – I don’t think the votes are of people that are too stupid to get it and be “manipulated” into an inadequate answer.

The BIG problem with QtQuick is that it wasn’t designed properly from the ground up – it should have been created as a public native API and then optionally use it through QML. Instead it has been designed to be exclusive to QML, and with no neat public API using QtQuick with C++ is extremely ugly, unintuitive and not documented.

Sadly this is a common practice for many big companies who create very good APIs using C++ but instead of providing a public native API they chose to make their product exclusive to their own proprietary language so it can gain more ground. This way developers are being force to adopt proprietary technology just so that they can make use of the features of those APIs, all of which are perfectly usable natively as well, provided of course, there is a public API to do so.

There is no issue of complexity with QML, some of the QML supporters claim people complain because they have to learn “another language” – I myself already know JS as well as a bunch of other programming languages, the issue of QML is not complexity but redundancy, it should have been made OPTIONAL, not MANDATORY. A very good example is XML GUI with QtGui – you can use XML, you can use the visual designer, or you can use the native C++ API to achieve the same purpose. Sadly, this is not the case with QML, while QML and visual designer are still options there is no option to avoid all the interfacing and all the design considerations you have to put into your project for the sake of utilizing the benefits of QtQuick.

The way I see it, QtQuick and QML has been a HUGE sinkhole in the development of Qt, it has consumed the vast majority of development effort since Nokia bought Qt, and even now Qt still falls behind schedule, Qt5 was supposed to be final in the beginning of the summer, so it is already half a year late, possibly more.

The way I see it, all this development effort could have yielded into much more benefits, functionality and features, and just to be sure, I don’t say the idea behind QtQuick is bad, it is the design and execution that have consumed way too much development effort.

I still use QtGui, so my priority would be Android and iOS support. On the other side, the development at Qt has been somewhat disappointing lately, which is the reason why I migrated all my non-performance-critical work towards PHP/JS internet applications. I myself am no big fan of either PHP or JS, so having the direction of Qt push me away from it into a direction I felt inferior should speak a lot of how I personally feel about the development at Qt.

And finally, don’t get me wrong, I am not saying QML sucks and there are plenty of scenarios I would gladly use it, however, in my field there are plenty of scenarios where I don’t really want to use it, and at the same time I neither want my applications to be dull and boring stock QtGui, nor I want to reinvent the wheel and use QtGui to go through the tedious process of implementing a modern GUI with animation and such. QtQuick solves a lot of problems, but it solves them in a way that forces a lot of extra tools and dependencies which are not really necessary. And making something that is not necessary into something mandatory is and will always be a bad idea.

Albert says:

Maybe I should avoid any comment, because I’m working with Qt since just an year ago, quite a little time to formulate a good opinion.
Anyway, I suppose that the youth of the whole QtQuick, QML and so on could be a good reason for waiting a before releasing a public C++ API. I mean: I immagine that in the current state the code is not stable enough, user cases are just facing up and probably we will see a lot of progress in this area before having a mature system.
So, maybe the idea of stabilizing an API at this time would produce some serious trouble in a near future, if for a reason or another the development team have to go trough an heavy API rework.

7 says:

Hopefully we will see a native API for QtQuick down the line, it would be the smart thing to do, not any later than Qt 5.2-3

I cannot shake the feeling it would be much harder to patch it in it later on compared to building it in right from the start. In that case, it would hopefully be a mistake your development team will learn from.

Also, instabilities in the API would be much more exposed if there was a public native API, which has its good side of ensuring the backend gets polished faster. By using QML certain flaws might not get exposed immediately if the QML API doesn’t go through those routines. I bet there is much more flexibility and possibility when using the QtQuick API directly instead of diving it with QML markup.

smoggy says:

BSD license + commercial support would have it spread even more.

What, you mean you want free commercial support? Yeah, that’ll surely would help. At least, as long as there was a fund of say $ 300 million to guarantee Qt would, despite the idiotic business model (‘none’), continue to be developed.

In absense of that, I know no employer who would willingly build upon a toolkit with no decent and obvious business model. The ‘freebies’ from Nokia weren’t all that popular and I know I would trust Digia far more to create a good Qt than a business who gave away the product because they don’t care about (most of) it.

So, in the Real World™, BSD license would lead to LESS spread of Qt. Now, potential users can see there’s a viable business model and Qt isn’t going away, so they can invest with confidence.

Chris says:

What is MEUR?

Dalius says:

I suspect it should have been “15M EUR” not “15 MEUR” – overall looks like money for salaries for those ~200 developers.

Ant says:

MEUR = Million of EUR.
Not only salaries for ~200 developers – also marketing budget, PR, translations, Qt Days and all these things…

Dalius says:

Yes, I agree. Development does not happen in the void.

Dalius says:

So far I’m very happy with Qt support for platforms that are officially supported (e.g. Symbian, Meego, Blackberry) so it would be very interesting to see similar level of support on other platforms – at least Android. I have looked into Android support in some 4.x versions and have concluded that it is not time yet so I wonder what 5.x will bring.

Chris says:

Symbian is out… already!

Dalius says:

I disagree with you but still would like to know what do you mean by that?

Chris says:

I think that Digia does not support Symbian. I’ve read about that in some announcement but I cannot remember where it was, so I cannot tell you about it exactly.

Ant says:

Wait, Qt LGPL supports Symbian and MeeGo as mobile platforms.
Using Qt Commercial you could not implement apps for mentioned mobile platforms, but using LGPL – why not?

And if now Digia also invests into Qt LGPL – we can say that Digia supports Symbian (through Qt LGPL).

Monse says:

That\’s an intellgient answer to a difficult question xxx

wildbillhiccup says:

Looks like someones trying to make Qt work in HTML5 too i.e. cross-compile a C++ + Qt app to javascript and html5:

http://ssj-gz.blogspot.co.uk/2012/11/quickie-qtcorejs-progress-update.html

Looks like its not the actual Qt gui yet, though.

7 says:

A lot of people are waiting on official and mature support for iOS and Android, which will make Qt THE best application development framework hands down. There are already plenty of frameworks that support major desktop platforms, there are plenty of frameworks that support major mobile platforms, but there is not even one framework that extends to both major desktop and mobile platforms at the same time keeping to highly efficient native code, allowing developers to target like 90% of the devices out there in the most powerful way without bothering with multiple different frameworks and languages.

Hopefully it won’t be long until Digia bring Android and iOS support to an official release level, I myself have been waiting for this for almost two years.

qqqq says:

I agree with 7, if Qt could could make QtQuick an option but not a mandatory would be better.
The animation framework of Cocoa are pretty easy to use and intuitive. Since Cocoa can do it,
I think Qt team is able to design a marvelous framework for native part of Qt too. Hope that digia
would let native part of Qt have the ability to use the power of QtQuick.

Tuukka Turunen says:

For 5.0 and subsequent releases Qt Quick 2, Qt Quick 1 and Qt C++ are all fully supported and developer can choose the best fit for his/her needs. So it is not mandatory to use Qt Quick with Qt 5. But in many applications it does bring benefits.

We have discussed how to improve, and one thing we hope to bring in is easier use of these together. It is already possible, but not as flexible as it could be.

It is our intention to develop both C++ and Qt Quick further – and naturally are open to do that together.

David Johnson says:

Lots of great stuff in QtQuick, but the implementation just falls flat. The QML language itself is not rigorously defined, and QtQuick 2 did not fix that so I suppose the quirkiness is now fixed for all of time. My two biggest issues, however, are the difficulty in integrating with C++, and the opaqueness of the framework itself. I have done several complex visualization widgets over the past year in QGraphicsView/C++ that would have been impossible in QtQuick/QML.

Tenurd says:

>#1 in developer experience

Stop insulting us with lies, please, at least don’t follow the nokia path and don’t spread lies like: “#1 in developer experience” … developers are very disappointed, you were warned to focus on more important issues, but the QML toy has drained all the work force. Qt 4 was in a nice moment in the industry, but suddenly all superficial aspects (“The Bling Thing” dependencies) gained more weight instead of improve technology for make better infrastructure applications: was a shot in your own foot.

>#1 in creating great user experiences

And by logic, if you don’t have happy developers then customers start to looking another solutions: basic mathematics.

Let’s wait that next versions (6) recovers the goal of be a “#1 in multi-platform support (read as C++)” without locks (like QML) for the GUI side.

7 says:

There is a fine line between a lie and a pretense.

I actually agree 100% that the native APIs of Qt indeed provide the best experience out there, not perfect, but certainly better than any other C++ framework I’ve dealt with. The problem is that QML is a departure from this, and not using QML, which actually offers even better user experience, but the extensive extension of QML, which is the problematic part. QML is great, especially for newbie developers, as long as you keep to stock components, the productivity of QML is unmatched if you already have the building blocks. But if you lean heavily on “out of the box” functionality, extending QML is much more tedious than simply writing all of your code in C++. That is, at least in my opinion, the BIG problem of QML.

QML is like LEGO, it allows developers to quickly build something up using neatly fitting components, for as long as the existing components fit the need. The problem is when you need custom components, you have to engineer and build molds of so you can produce the custom component. And the problem is not with one, two or a few components, the problem is with numerous custom components, combined with very low component reuse which doesn’t really justify extending and interfacing a component. It is here that QML completely fails and goes against the ease and simplicity of use it was designed to provide. The other tool, which Qt provides for such scenarios – QtGui is outdated and fundamentally designed against the concept of modern GUI, with state and animation merely hacked in as a clumsy external module. QtQUick solves that by being designed with all those new features in mind, but makes it mandatory to extensively extend QML due to the lack of a native public API.

What is amazing is the persistent refusal of Qt management to admit this simple issue, instead acting as if QML is the greatest thing since sliced bread. Wake up, QML is merely markup. The FUNDAMENTAL mistake of Qt management was implementing QML in the private QtQuick API, leaving it without a public one. If they first did a public native API for QtQuick and used it to implement QML it would have been much easier to do, much easier to maintain and improve upon, and last but not least, QML wouldn’t be mandatory to use QML.

Slartibart says:

Why do you, and others ranting on about C++ QtQuick “support”, consistently ignore the Qt teams response, and instead blame them for “not communicating”/admitting “failure” when the real problem apperas to be a rather lacking basic technical understanding from your part? Oxymorons such as “QML wouldn’t be mandatory to use QML” (not sure wheter that is a typo?), vague hints at “made public instead of private” (completly ignoring requirements and drawbacks with “public” API’s – and completly ignoring that it’s not merely a matter of making some API’s public), references to “native” in a context that make absolutely no sense and comparisons with XML (which staticly parse to C++ code) just make you look like another “angry lemming”.

Sorry for being so harsh, but I’ve had quite enough of guys looking to “blame” someone for not having the same personal goals as they do, particularily when they don’t appear to have enough knowledge to define what they think is wrong an how it can be improved. I’m not an expert, but I don’t need to be one to see the glaring flaws in your rationale and to see that the explanation the Qt architects makes much more sense. It doesn’t help you case that Microsoft just has made an epic effort to do virtually the same as QtQuick/QML either (ever heard of Silverlight/XAML/WinRT?).

danny says:

’7′ could have worded that better and I’m a little tired of seeing that silly poll trotted out too but his frustrations are not unique. Qt is a ‘well established’ and ‘well recognized’ technology *because* of it’s C++ foundation, not in spite of it.

“It doesn’t help you case that Microsoft just has made an epic effort to do virtually the same as QtQuick/QML either (ever heard of Silverlight/XAML/WinRT?).”

The difference is that Microsoft have the resources (and a strong incentive) to create such platforms. Qt has only a handful of developers left and their time would be better spent fixing the issues that exist in Qt right now that make it such a pain to use in non-trivial projects. I use Qt commercially and have lost count of the *days* I’ve spent working around broken Qt features or badly designed components.

Yes it’s hard work to create an interface with the old QWidgets and that’s largely due to the monolithic one-size-fits all paradigm of the Qt framework. This could have been fixed with a redesign of that API, using the new MVC classes that were originally proposed back in 2009 (NGViews etc). It is possible to write very clean, very intuitive code with C++. And Qt should do what it does best – UIs and custom UIs. Leave the networking, concurrency, XML parsing etc to dedicated libraries that do a better job

We didn’t need yet another high-level mark-up language. To use your example, it would have made more sense to go down the HTML5 route for mobile and touch UIs. That’s a recognized, evolving standard that would have helped Qt adoption. QML by comparison is a propriety technology managed by one company and usable only from one toolkit. It requires good knowledge of existing Qt classes to work. What is the incentive for us devs to adopt would could easily turn out to be another ‘framework of the month’?

Apple didn’t need to invent a whole new language for Cocoa Touch. And let’s face it. Cocoa Touch is what kicked off this whole race to mobile in the first place.

The C++ API provides job security in a rapidly evolving industry and benefits from the ongoing improvements in the compilers and the language. Qt and Digia get this ‘for free’. That’s the benefit of using an industry standard platform. Even Microsoft, who drag their feet when it comes to standards and pushed their managed ‘easier’ languages for a decade have swung back to C++. Silverlight is dead and .Net may well follow it.

I have tried QtQuick. I’ve worked through the examples. Yes it’s easier to throw together a UI using QML states and some of the tech is impressive. But integrating that all-or-nothing platform with existing business logic is much, much harder and is dependant on the antiquated QMetaType system and a heavy runtime. It requires a greater understand of Qt’s C++ classes than when developing QWidget-based UIs! And while Quick receives all the attention, the core Qt API that made Qt a success and QML possible is falling behind the curve.

Digia have stated many times that are fully committed to C++ but actions speak louder than words. I’ve downloaded and tested every major Qt beta since 4.6 and I’ve noticed a definite degradation in quality. Hitting bugs like QTBUG-27862 or QTBUG-6127 makes me question Qt’s priorities.

7 says:

“Oxymorons such as “QML wouldn’t be mandatory to use QML” (not sure wheter that is a typo?)”

It is obviously a typo, read as “QML wouldn’t be mandatory to use QtQuick”.

There is no need to insult me by the way, neither by calling me an “angry lemming”, nor by inferring I don’t know what I am talking about. Those are cheap and pathetic ways to put under question the adequacy of my concerns. There is no lack of technical understanding on the subject, a public native API would have been a faction of the work that was needed to hack in JS and implement QML with the private API, which is quite ugly to say the least. QuQuick 2 could have been ready a long time ago and Qt5 – on schedule, if it wasn’t all the pushing to make QML the exclusive frontend to a C++ backend. A public API could have come almost for free, if the internals of QtQuick were designed to conform to a public native API, which they are so obviously not, much more resembling a messed up bundle of tangled random wires. But this is to be expected, since obviously, there was no public API intended in the design phase, so in a way you are right, a public API would require a lot of effort, but entirely due to a stupid design decision, for which I am pretty sure I am not to blame…

And I don’t really put it in the context of “blaming” but nevertheless – it is an issue of Qt and a responsibility of its developers, not mine, not of any other independent developer. Obviously, it is not just me, there are way too many people sharing my concerns to be ignored – it is not a question of my or anyone else’s personal goals, it is a question of the collective, mutual needs of the developer base of Qt. Well, it isn’t really, at least not at this moment, but it should be, for the good of the framework itself.

Last time I checked, Microsoft were actually abandoning Silverlight, XAML has little to do with QML and is much more an equivalent to QtGui with XML, and WinRT actually HAS a public native API. Surely, MS have done what it takes to mess it up and make it incompatible with standard C++, but still, it is a native API, and WinRT is usable not only with C#, VB and proprietary MS stuff like that, it has a public C++ API. In fact, you can even use JS to build WinRT applications, but IT IS OPTIONAL, NOT MANDATORY. And if Microsoft, one of the worst companies out there, if not THE WORST in terms of extorting and conforming developers actually does better than Qt in this regard – well WHOOPTY FUCK@#’ DOO!!!

Looks like it is you who is short of technical knowledge, which perfectly explains your tactics of attempting to put the credibility of my opinion in question…

Fabio says:

Your opinion make sense to me too, despite any denigratory (but without argument) answer I read.

And I think this is true for the most readers.

David Johnson says:

QtQuick advocates correctly point out one major limitation of QPainter: sequential painting. But unofficially deprecating widgets and graphics view was not the solution. Imagine a Graphics View that was backed by the new scene graph. Very little of the API would have needed to change. Instead of drawing the items sequentially they could have been drawn in parallel. But leaders of the Qt project decided against this, and so all the power of Graphics View will rot in the background while developers struggle with a new framework that’s not well suited to their tasks.

Carter says:

No, not sequential painting, imperative painting, which hasn’t been deprecated by Qt, but rather by modern graphics hardware, which requires you to have a state-based drawing model like the scenegraph used by QtQuick instead of an imperative drawing model like QPainter.

If you n-parallel your imperative painting you just slow down your drawing operation n-times, most probably way more.

And that’s exactly the problem of this tiresome discussion. People without the theoretical and practical expertise cry foul, just to ‘shut down’ when people having the required knowledge speak.

If you are used to your QGraphicsView and QPainter either use it without QtQuick (both will be around for at least another decade) or with QtQuick (as a QPainter-based QtQuick API is still offered).

David Johnson says:

Imagine you need to “draw” a pie chart. Using QPainter it’s very straightforward, so easy that it’s one of the exercises in the official Digia Qt training class. But without QPainter it’s extremely difficult. This is why I say QML makes easy things easier and hard things harder.

I AM NOT SUGGESTING that the pie chart be painted sixty times a second, that’s just silly. Yet I think that’s what you imagine QPainting rendering to be. If the pie chart is static, I only need to draw it once. If it’s animated, then I render it to a QPixmap first and then either blit it or make it a texture.

Carter says:

(To the comment of David Johnson below or above, wherever it might be placed)

Why should it be extremly difficult not using the QPainter API? Just create your own QQuickItem-based class as you did with QWidget or QGraphicsItem or directly draw the chart using the QML Canvas item. There is no difference in difficulty, it is just different – for a reason.

At the risk of repeating: You can’t use the existing QPainter API with modern graphics hardware and expect decent acceleartion because it the imperative QPainter API is incompatible (!) to the state-based drawing model required by the hardware, be it either serial or parallel, be it 25 times or 60 times a second, be it a texture or a framebuffer object. The performance advantage QtQuick has over QPainter is solely based on not using the imperative QPainter API.

If it is extremly difficult for you (!) to not use the QPainter API just use QQuickPaintedItem which offers a way to use the QPainter API with QtQuick and does exactly what you’ve described: it is drawn once to a texture using CPU rasterization and blitted by the GPU when needed. But you do so at the cost of losing hardware acceleration, because you (!) have decided to stick with an API which has been tailored towards CPU rasterization and has been made obsolte a decade ago by graphics hardware (!). That’s something Qt won’t and can’t change for you.

So you either stick to QtWidgets / QGrapvicsView, which are still first class citizens of Qt for at least another decade, or you switch to QtQuick and QQuickPaintedItem using the QPainter API and hazard the self-imposed performance penalty – or – you just accept the fact that technology has moved on in an incompatible way to the past, learn something new and unleash the power of modern graphics hardware using the scenegraph generously brought to you by QtQuick.

But don’t come here and blame Qt for your decisions.

A lot of people – including me – have already decided to do so and they are really thankful for Qt providing a way to express hardware-accelerated, declarative graphical interfaces – because that’s where technology is (or already has been) moving to.

terry says:

You guys still fighting about QML, I don’t know QML would success or not, but the users(including me) really need a
good book about how to make a good use of QML.Anybody could write a book about QML?

Carter says:

No, we are still fighting over that people do not even understand the difference between QML and QtQuick and the technical background which required to create both.

Slartibart says:

You don’t speak for everyone, I for one welcome Qt in the new paradigm og UI creation, staticly compiled GUI Widgets are so 1990′s.

fonzi337 says:

I agree. While I’m sure QWidget-based applications have their uses, one cannot match the ease of developing a UI in a declarative/QtQuick environment in C++. What is truly lacking in QtQuick at the moment are the desktop components for desktop application development, but once those are released, I think QtQuick will be a fantastic complete package.

terry says:

>desktop components for desktop application development
Will these components be able to cross other platforms but not just desktop?
It is weird to show desktop UI on mobiles, but it would be very convenient
if I don’t have to recreate the UI for different platforms when I don’t care about it

Jens says:

Nothing stops the desktops components from running or deploying on any device as long as it already has some rudimentary support for widgets. (that includes most of them) It would still be mostly unusable (but might perhaps just be enough to trick a customer into thinking that mobile support is available…)

However, do consider that a big part of the reason why this is important to you now is the significant effort that is currently required in maintaining a qwidget-based UI and how much effort is required to maintain multiple versions of the same UI. On the other hand, if you already have a UI written in QML, it would be a lot less effort to create another one that is significantly better suited towards mobile and touch based use.

terry says:

I tried QML before, there are only two things stop me to use it

(1) lack of components, it is easier to use QWidget to finish my job since there are more components could be used.
Create a brand new desktop like QML components could be pretty difficult.

(2)There are a lot of documents and informations, but scattered.QML is a new language, I don’t have any
experiences about develop a big system with QML, C++ and JS. If we could have some good books to
guide us, would be highly appreciated.

Tuukka Turunen says:

@Tenurd: The mentioned items are our goals for 2017. While it is possible to say many of these are true already now, that was actually not said in the blog. Qt 5.0 is the beginning, not the end. And for sure we have not forgotten C++. Actually Qt 5.0 has quite much improved in this respect compared to Qt 4.x – and we will continue to improve in 5.x versions.

d3fault says:

Qt has already accomplished all 5 of those “goals” right now in 2012!!

Still, it’s nice to see Digia plans on ditching second place even further by adding iOS/Android support :-D . Any competitor’s 2025 goal will be “catch up to Qt 2012 version”. lol.

CN says:

People cannot access Youtube from China Mainland…

Jolla says:

Would you support Jolla or Sailfish OS officially?

Jens says:

Jolla: We do not have to. Jolla is using Qt natively in their SDK and will maintain their own official Qt releases. We are already working closely together with them to make sure they get full support in our development tools like Qt Creator.

José Arcángel Salazar Delgado says:

I know that everyone wants support for android and IOS. But, Is there any possibility that digia retake the bindings of Qt in Java?
The current GUI frameworks in java are old and missing many features that Qt have. I’m still working with the old qt jambi 4.5 because we don’t have anything to use in replacement. And the community bindings of QT jambi 4.6 and 4.7 don´t have Win64 port.

7 says:

Why would you use Qt with Java, since Java apps require the runtime and the library which is very well rounded and cross platform? I would understand it if was something like Python… but Java?

Anyway, with the current priorities of Qt I wouldn’t put my hopes up if I were you, the bindings are much more likely to come from the community.

José Arcángel Salazar Delgado says:

We have very specific requirements that need java to develop and we don’t have a good framework in java to make good GUIs apoart from QT jambi. Well, I should migrate to JavaFX or E4…

Darryl Miles says:

@JASD The Qt Jambi project works and builds against Qt 4.5.x through to 4.8.x including Win64 (including MSVC2008, MSVC2010, mingw-w64) as well as all the other major desktop platforms. Maybe you should just attempt to build Qt Jambi from the qtjambi-community git tree. Building of Qt Jambi has hopefully gotten much less painful now.

@7 Your comment about well rounded and cross platform is very funny. Most axillary APIs Qt provides are inferior to the available APIs available in JDK or the Java ecosystem. However many other aspect of Qt APIs in the areas of UI, QML and WebKit still currently provide a significantly useful alternative to the Java ecosystem is that continue to make it a very viable choice. Hopefully in JDK9 when the modularization is addressed it will be possible to completely pick exactly whose implementation of which elements you want to include in a project.

José Arcángel Salazar Delgado says:

@Darryl OK, I will try to build QT jambi for win64.

@7 We need to use Java because we need compatibility with a Web App build with java and we recycle code. Also we need JasperReports, Apache POI, Apache Axis, Spring, Eclipselink, etc…

TheTrueDigia says:

“Digia’s rationale to invest in Qt is commercial by nature”
My dear developers prepare to be milked! Might I remember you all what’s a good cow behavior?
Give enough milk everyday.
Don’t complain, because you will be served food and believe it or not it might be beneficial to you.

and finally

if(outOfMilk)
return slaughterHouse;

vipyami says:

Sorry for my poor english, but as a programmer has more than 10 years experience, I want to tell you, kill QML, do as ’7′ says, focus on the native API, focus on Android and IOS, remember you just only ~100 programmers! The QML is history, you should face to the future. Don’t answer me ‘SliverLight’, For client development, I has used VCL, MFC, Swing, QT in past 10 years and now javaFX. you should know, all the users of QT are C++ programmers, you want them use QML to develop their key software?

Mark says:

Please improve the Mac OS X support to feel more native: more widgets, more integration!
We need it for Mac App Store.
And Keep focus on C++.

Thanks a lot for your effort.
Very appreciated.

Philip says:

I agree with Mark: keep focus on C++ and for “not c++ fans” spread the usage of PySide.

Commenting closed.