The Qt Project is live!

Thanks everybody involved. This has been long brewing, it's a very complicated process, but I think very worthwhile.

Great news! Congratulations are well deserved!

I was looking around in Gerrit and I didn't figure out how to see who are the current Maintainers and Approvers.

any replacement for this blog? or will it stay like this?

Congratulations! This is a major step for Qt!

Tuukka Turunen
Director, R&D
Digia, Qt Commercial

I know this has been a LOT of work for the people involved. Thanks for getting there in the end!

Really happy to see this announcement!! Thanks to everyone involved.

@Kenneth: see http://developer.qt.nokia.c... for now, apparently

Congratulations!

Beautiful in every way. I see this move with open governance as the next step in open source and as a test for the model of open governance done by a most excellent community that will set the standards and maybe transpose these lessons to other projects even outside software development.

Thanks guys.

Cool! Congrats to all involved, and big thanks from us Qt lovers... :)

I watched "Code Rush" (http://clickmovement.org/co...), yesterday.

Sorry to seem negative, but it looks to me like the beginning of the end of the involvment of Nokia in Qt, a bit like the last struggling days of Netscape.

On a positive side, really opening Qt to the community is great!

Great news!

One question though: Why put the whole review board system behind a login wall, instead of making it publicly readable and only require login for write access? Technical reasons or political?

"but it looks to me like the beginning of the end of the involvment of Nokia in Qt, a bit like the last struggling days of Netscape."

Chris nailed it.

Nokia doesn't need Qt now.
Nokia will unveil his first Windows Phone next week.

Nokia&Microsoft are just poisoning Qt with Qtquick and qt5 shit.

The open governance work started more than a year ago. It has gone through all the changes at Nokia, it will go through the current and future Qt based products from Nokia, and it will also go through whatever superficial skepticism the project gets. Said that, my first contribtion to the Qt Project probably will be a wiki page answering the repetitive arguments coming from people with the best of intentions but perhaps not aware of the big picture or well founded information.

Quim: the problem is that we know now that Qt in Symbian is pointless because Symbian is pointless (long term) and that the MeeGo brand is tainted, and nobody seems interested in using it.

So for outsiders, is impossible to see why Nokia is interested in Qt at all when is not coming to Windows Phone. Unless Nokia explains what this "Qt for the next billion" is, you will get this bitter replies. We thought that "next billion" was the buzzword for S40 phones, but this is not said explicitly. I don't understand why something more clear is said to Qt developers. We don't care if is Meltemi, S40, or a successor to the N9.

That said, I see that there is still involvement of Nokia in having Qt development going on, so I'm moderately optimistic, and since IMHO Qt is so freaking good on the Linux desktop, I still see good things in Qt's future.

I know that my words are hard. And unfair.
But believe me... I love QT. I love the people who created it.
But yes. Im very skeptical about qml.
I dont see people demanding it.
I dont undertand the focus on it over qwidget.
I dont see it better than other alternatives in declarative programmimg (qt c++ is better than any other alternative).
I dont see alive platforms where deploy it.
I dont understand why qml things get great maintainers... and other important things dont.
I dont understand why most Desktops things are: "status done. require maintainer".
I dont want a port of qml to android & iphone.... because that platforms has good sdks and ndks (and as user I dont want an app with the extra overhead and battery draining of qt libs)
I don't see future in qml for desktops at all.

summarizing:
If I want to make mobile apps -> android and ios sdk is the way to go.
If I want to make desktop apps -> qt c++ is the way to go.
XXXXXXXXXXXXXXXXXXXXXXXXX-> qml is the way to go.
Solve the X.

I have not used Qt for several months since Elop made ​​his decision. I view this blog everyday and just wait and hope. Today i see only one way for Qt library perspective in mobile sector - support Android, iOS, Windows Phone. Three giant of industry: Google, Apple, Microsoft. Nokia and Intel now in tail, so no MeeGo and no Symbian. The ideology closest to me is MeeGo. Richard Green - you are MAN!

Hi @soy. I'm glad that you're moderate optimistic. You're not alone. Nokia has hired Qt developers for a while now and we still got job openings. We are constantly working on a lot of interesting Qt technology, helping application developers in 70 different industries on all kinds of form factors.

Of course with the Qt Project our support for free software communities is on pair with, and some will claim its better than other free software projects. As an added bonus Qt is core for the next billion, as Stephen Elop explains it when he visited China a little while ago. Please watch the interview (2m49s - 4m00s):

http://www.youtube.com/watc...

I recommend you to celebrate the Qt Project with a cake. Today is a historic day!

Javi Moya: on QML you can write app for mobile and desktop at the same time. As Microsoft Windows 8. More huge rectangles on monitor and all happy :)

You know, at the end what counts in a free software project is code and releases. The Qt project is following a fantastic path with 4.7, 4.8 and 5.0 development with plenty of new features and huge improvements. That is objective data, easy to track and evaluate.

The QWidget / QML discussion is orthogonal to the open governance discussion. Except that the Qt Project provides better tools to those willing to focus their involvement in QWidget maintenance. If you like QWidget (or whatever else is not a priority to Nokia, who was the sole owner in the previous setup) then the Qt Project is good news to you.

...and if you like QML (or whatever else is at the forefront of Qt 5 development) then the Qt Project is also good news to you, since now you have the same access and opportunities regardless of your affiliation.

As Knut says, today is an historic day to celebrate. Enjoy!

@SABROG:
No, you really can't write true, complicated desktop programs with QML. It is only at the demo stage currently if you think of true desktop programming. Widget-based Qt is well matured and contains massive functionality supporting desktop application programming. It will require years (if not ten) of hard work to get the QML in an equivalent stage, desktop programming sense.

There is more to it...many people use IDE:s/tools different from Qt Creator and I could imagine for example Visual Studio + QML being a kind of cumbersome combination. Haven't tried though. Also creating a dependency to a another language is not something that C++ - programmers wish.

Like I've said before, widget based Qt is widely used and truly respected by its users, crippling it will/would be really stupid. It should exist and keep on evolving long into the future.

QML is interesting, but does not really serve desktop usage at the moment.

Anyways, congratulations for the project. Thanks for the trolls for this superior piece of software!

First @Moya, touch and animations are here to stay. Now that smart phones with touch are sold in way greater numbers in many western countries, there are no way back. Touch and animations are used on small surfaces as Nokia N9, tablets or bigger surfaces. This was invented in 1991 by Pierre Wellner. It's 20 years ago. Of course todays solution is way better than the initial prototype which coined the technology as this video shows: http://www.youtube.com/watc...

We absolutely need to support this 20 year old multi-touch and pinch way of doing UI's. This because of all the new form factors where the keyboard+mouse (or stylus) are replaced by touch and on screen keys input methods.

The second challenge from a programmers persepctive, is that imperative languages as C++ need you to "micro manage" your objects around when making those fluent animations and such, making you produce tons of glue code to make it work. Even if you got a nice state machine, animation API's and such, you end up gluing a lot. Going for a declarative language is much easier, and needs fewer lines of code. This since you're commanding where objects should go to, and how they should behave, instead of "micro manage" them with imperatives. This is why Qt Meta-object Language is so powerful for those User Interface use cases.

An added bonus of using a declarative language, is that designers understands it. Hey, even my mother can get a hang of it. Then designers can work much closer with developers, where developers can add the needed "mechanics" directly to the designers work. Then you don't loose design features which might happen when designers works with Flash, and expects programmers to make the same in C++ (due to speed considerations, deployment and licenses issues etc.).

As a last practical argument, Qt is cross platform allowing you to reuse all or most of your code on different devices. Instead of having two or three code-bases, you can deploy your Symbian or MeeGo N9 app also on Android. You might even take a shot on iPhone. Developers have.

Of course, If you don't got any interest in new forms of User Experience based on touch and animation, "old school" desktop API's works as well with Qt. And we now got new developers contributing to Qt both commercially and from the community. A couple of weeks ago we got a three way meeting with Digia, core KDE developers and Nokia on how to get more desktop oriented contributions to Qt going forward. At Qt Dev.Days we will have a Qt Contribution Day working to make this happen. With the Qt Project there are nothing stopping us in making Qt even better than before.

Some trivial bug reports take forever to resolve:
https://bugreports.qt.nokia...

Knut Yrvin:
thank you for your response.
I understand your arguments...
but...

do you imagine a Visual Studio app made in QML?
or a powerful Excel app?
or a Database explorer app?
or a pro Video editing app ?
or qt creator?
or an internet browser?
Thats what C++ coders do.
Not twitter clients.
Not weather apps.

I understand that qml is a great addition. New possibilities. But QT is mainly a framework for serious things. For performance. For "micro manage". Most of their users we choose QT because of that. Because is better than any other c++ alternative.

As I said qml is a great addition... but you cant focus qt on it.
You see clearly on Microsoft vision for Windows 8:
¿you want declarative programming apps? go HTML5 and javascript.
¿you want desktop apps? go .NET.

Declarative is here to stay and grow. Yes. But desktop too.

Qt is open governance now. But people is very skeptical about contribute on it... because they dont see Nokia maintainers working for desktop things. Qt is not going to get enough external contributions if their main supporters now (Nokia maintainers), in the beggining of the project, are not supporting anymore the core and soul of QT.

QWidget is available and maintained in Qt 5 and you will be able to develop all those complex desktop apps with it if youwish so. This has been argued until exhaustion (the last time just few days ago in the Qt5-feedback mailing list. If you want to contribute to a fruitful discussion please go to the appropriate bug reports or mailing list and provide specific details / improvements. Thank you for your understanding and your Qt passion. :)

Congratulations and thanks to everyone involved. I love qt and hope it prospers with the love and contributions of the community and Nokia.

Desktop is dying. Only pro computer people and devs will use Desktop computers in some years.

QML is the way to go for "touchscreen devices", and I am sure we will se ALOT of touchscreen "consumer devices" everywhere in some years. And I hope they will be based on Qt.'

Even Linux dists is going this direction Gnome/KDE (means HTML5/Qt etc...)

But it seems people STILL has been confused about QML cause you still can use C++ in the apps!
C++ will NEVER be replaced fully by QML/Javascript.

And all this whining about no QtWidgets. Well start contribute then! Its what opensource is about!

Why do you think Nokia would have ANY intrests in QtWidget? With or without Eflop this was the direction to go for them.

Soo I am glad Qt is finally fully open source.

But there is things that scares me a bit! Is this too late already? Will the linux dists improve development on KDE+Qt now or will they totally go Gnome direction?

A bit oftopic maybe..

@Iouri Goussev they fix this bug, here is the commit:
http://qt.gitorious.org/qt/...

I can inform you @Moya that there are new Qt contributors registering every hour now. There were almost as many external participants at Qt Contributors Summit in Berlin this summer, as Nokia employed Qt contributors. The pressure I got from the community has been immense, demanding execution on Open Governance. Developers have been worried. Afraid their contributions would not get in before the Qt 5 feature freeze.

I think some in the Qt user community has taken the QWidgets-story out of context, stating wrongly that it will go away or something. QWidgets will stay. The re-architecture of the graphics stack is done to improve Qt even more, based on years of experience with the Qt4 series. This improvements benefits the "old school" desktop too. This is a nice side effect when making Qt as lean and mean as possible with as much bling as possible, targeting low powered hardware.

I'm looking forward to meet some of the contributors at Qt Developer Days in Munich and later in San Francisco. If you haven't joined yet, I hope you will. It's more interesting to be a contributor than a spectator. Others who have joined are already working together to contribute more, as this blog post shows:

http://blog.qt.nokia.com/20...

Better to use https: https://codereview.qt-proje... so the fetch urls the reviews give actually work.

On the new project website in the first paragraph, there is a typo: "To can learn more". Someone should fix it.

恭喜qt上线

@Knut, QML is a nice tech, it makes UI design and program easier. But QML is a brand new language(js-style though) and its syntax is a little tedious. UI desigers don't like coding, so my suggestion is making QML UI designer better and stronger, so that designers can visually realize their concepts and do not need to care much about the new language at all.

For the people wondering if QT will disapear, consider that it was developed in 1992. This was before Java, .net, or even Google existed. Most of the world hadn't used Windows at this time. Consider KDE, which is one of the most common desktops (in the top 5 for sure) just turned 15 years of age last week. Many of Qt's maintianers such as Thiago Macieira who was mentioned in the article are also long time KDE developers.

I've been using Linux with KDE as my desktop OS for 10 years now and I don't see that changing.

Please make some videos to show how to push patches and review code etc. with qt-project...Thank you!

There is a bug at the front page of www.qt-project.org:

To can learn more ---> To learn more

Congrats !!

It's sounds lke "Nokia will no longer support QT". This is the end? And what about Qt Creator?

Lately Qt is insanely bloated with all the Qml and QtQuick, Qt is not as before, Qt before was a high performance super awesome C++ framework.

Look Qt community lets work together for unbloat Qt from that crap and get Qt with C++ on track again as a fast and unbloated framework. for bloated and slow frameworks with virtual machines executing scripts or javascript I will go with Java and the JVM but with Qt I dont want that. I want to develop with C++11, High performance unbloated framework.

Microsoft is getting rid of manage environments and going back to native development with Windows 8 so with that Qt could learn from the mistakes of others. Cut the crap and get Qt/C++ again on track.

Fork Qt and drop all QML and nosense garbage. I want my C++/Qt back as before.

@kubivan: Looks to be active. http://labs.qt.nokia.com/20... and 230 commits in the master branch during the last three weeks.

Sorry for many post but right now is hot this forum.

If we contribute to the Qt project in full steam we could modulate Qt with just the core and the GUI with OpenGL ES and port it to Apple IOS and Android that are the hottest Mobile devices right now. Qt/C++ it is native development and can run on those platforms so forget Nokia and Symbian, lets port Qt to IOS and Android.

Symbian it is already a dead platform, Nokia if does not have a success with Windows phones it is dead also. So anyway this is good news that Qt is already 100% opensource community driven software.

@Miloskov: maybe Qt is bigger than before, but it is more performant too (speed). I'm speaking as a Desktop C+ user of 4.8 RC-1.
Supporting mobiles with their small CPUs, has "obliged" Qt programmers to make it more performant.
And since Qt is becoming more and more modular, I see no problem.

Iouri Goussev: Well, now with OpenGov, you can submit such trivial fixes yourself. Finding a reviewer won't be hard, too. So this actually improves things.

Very unfortunate that this excellent framework is being turned into what I would call "Visual JavaScript for Mobile Devices". I mean, the very fact that our beloved Qt Widgets have been demoted to an "Add-On" while something like Qt Location has made it into "Essentials", really speaks volumes:

http://developer.qt.nokia.c...

Having said that, I still wish the new Qt Project all the best!

Congratulations! Although my English is not good (from China), but I will do some code submitted for interested project, such as QtCreator.
So, Let's less some discussion, just do what you like.

Congratulations!

I honestly find the hostility towards QML rather ridiculous. The ways of interaction with computers in some fields are changing, not just mobile but desktop too. You are ignoring the fact that QML is really just another kind of widget. Hardly anybody complains that we have declarative view because every once in a while we need vector elements in our UI. Now we can have fluidly animated interaction elements too.
I remember drooling over such desktop UI features back when Rasterman did it for E17 way before Qt got on the thick-UI-tier versus logic-tier bandwagon (and that was a homage, in case you didn't notice - he still beats you on elegance). E17 too had a separate javascript-like language for controlling the UI. Use the right tool for the job, and a native language sometimes is.
Sure, QML must mature and become even simpler to learn while yet more powerful, since it is indeed a niche phenomenon only useful inside the Qt world. But hey, it's still young.

Straight slim C++ and widgets? Sure, I can see the need and rationale. So you modularize all of Qt to satisfy the needs of everybody. But please folks, respect that some people have other needs as well.
In the future I find it hard to imagine a video editing application that does NOT include QML in some form. Or even further: Imagine you could hook your mobile phone to your editing app and turn in into a passive touch-enabled controlling device for scrubbing etc. Cheap touch-LCDs will come, who knows, perhaps embedded directly into the keyboard.
Asset management in every kind of media related application? Say hello to QML.
The old-schoolers keep seeing animations as unnecessary bling. But animations (when used carefully) helps the brain retain a sense of connection between changed states of the UI. How many users of old-school programs have been glaring at the screen looking for the button they just pressed with a "where did it go?"-expression on their face? Animate it.

As for the QWidget space, I again fail to see the complaints. Taking the road of establishing a framework that can support the next generation of widgets by first solving an immediate goal and making money on that - well, it sounds like damn good resource management to me. You don't get a lot of chances to do research into prospective technologies without a huge economical surplus which I doubt Trolltech had. Both Nokia and the rest of us will harvest from that strategy more than once. Well played, Qt.

I can't imagine standard Qt widgets being used in future interfaces. The architecture doen't fit for animated interfaces. Apple saw that and introduced Core Animation and Core Graphics and that work very well with Cocoa.

QML is a technology that will make Qt a great tool to develop such interfaces! Thanks for this great step!

@Miloskov:
"Fork Qt and drop all QML and nosense garbage. I want my C++/Qt back as before."

That would be the most unwanted situation. I think nobody wishes or wants to see Qt forked.

What I would like to see as a Qt user and mainly Qt widget user is a hand to hand evolvement of Qt widget and QML-stuff. Use what you want and need. I understand that glue is needed to provide QML goodness for C++ programmers, but that is just what Qt is and has always been...a lot of hard work in order to provide truly usable api's for the developers.

@Rene Jensen:
"I honestly find the hostility towards QML rather ridiculous."

I can partially understand it, widget developers feel being left in a secondary position and feel that the development of the tool they are using is under a threat of going into a stall in the future. There are many really big and complicated apps coded using widgets, plain C++ and QML doesn't feel appealing in such use cases. Plus, the fact is that at the moment QML isn't really ready for serious desktop development.

Comments like presented João Barbosa isn't helping QML gaining more love...if the only purpose is to piss up people, better leave it unsaid. If you don't have any reasons to use Qt widgets, thats all fine. But it doesn't mean that you have an understanding of what others need.

off topic, I know but damn: http://www.engadget.com/201...

I have a question regarding the Qt Project page: I am the author of free software based on Qt. I include the homepage for Qt, so that users can download Qt and compile my application by themselves. Until recently, the link I put there was qt.nokia.com. Should I switch to the new qt-project.org, or keep the old link? I mean, I did not see direct download links on qt-project.org, and I see now that it is mainly a developers site.

@JubiluM: Certainly I can understand that users of traditional widgets feel left out. But I repeat the claim that the QML detour could very well be directly beneficial to traditional widgets (perhaps in Qt5, right?).

Some years back I made 3 or 4 homebrewn widget toolkits myself either on top of OpenGL or straight X11/GDI. For the accustomed eye, it becomes fairly easy to spot when a UI-toolkit has restrained itself from further growth. Qt widgets were in that pit, in my view. It would require a good amount of money to push styling and look'n'feel (which IS somewhat important, even to the office people, and especially to the digital content people - examine the mess that is Maya a few versions back, to see what Qt looks like done wrong).

If you want finesse, you need a powerful styling+look'n'feel foundation which is also fairly easy to furnish with assets for the design people. The QPainter system looked more like a ceiling than a staircase (in that particular regard).
Once the tedious chore of inventing a sound foundation is done (and even paid for), they can move back to better and more useful widgets without any restrictions. And widget users can always scavange for a complete look'n'feel somewhere without needing to get their hands dirty with Photoshop. If you are limited on development resources, I still say it was a clever path.

Of course, once the job is finished, nothing stops them from spending more time on porting to other platforms and creating new high-level widgets and tools... ;-)

@Goer, the video for contributing and reviewing code is already available. You can find it here: http://developer.qt.nokia.c...

@JubiluM

I don't want to "sell" QML :) But, putting it simpler, if in Qt5 the current Qt widgets are "painted" in QML then it's a question of abstraction, besides the benefits of QML for creating richer interfaces.

On the technical side, enabling the gpu to render the interface is a great step forward.

@Rene Jensen:
Of course it would be desirable to let people decide what to use...even better, use both widgets and qml in a same app if they will.

I can not share the your view that Qt widgets as a UI-toolkit would have restrained itself from further growth. I think it is a common misunderstanding of each others' needs between mobile/web developers and widget/desktop - developers in a context of discussing QML vs. widgets. Widget programmers do not actually care so much about styling, bling bling, etc., more important is that there are useful api's to give help to get some complicated stuff done. Also native look of applications on each platform is one important factor. Of course, nobody complains if there is also eye candy availlable, animations etc.

What I mean by functionality is, for example, 2D graphics with support for printing, print preview, 3D graphics, tables (a la QicsTable). There are lots of additional 3rd party components written to ease widget developers' lives and first of all, it will take a lot of time to write equal functionality into QML plus it will take a lot of time to port existing applications into QML.

And then there are other issues as well...what if I am not using Qt Creator...is there a natural way to use Visual Studio to develop QML? How easy it is to connect to other C++/C - libraries...say I am writing a CAD application, is it easy to connect ui to a CAD kernel, say OpenCascade?

The nature and needs of mobile development are somewhat different from desktop development. We need to understand each others' needs better in order to enhance the communication. I think that the right way to go is the mutual evolvement of widget and QML - Qt.

@João Barbosa:
That's ok from a technological perspective...you will not hear any cry from widget developers' side by saying that you have enhanced something under the hood :). Not many "end users" care about the technical details, but of course you are gladly greeted if there is improvement in functionality, performance etc.

But it is not, at all, about how something is done technically...like I said, you got thousands if not hundreds of thousands users that use the widget API and are satisfied with it. Who love it. Expect it to evolve. Imagine what happened if you were to say that hey guys, we got this new thing called QML, throw that ol' C++ into garbage can, what we got here now, is Javascript ;)!

I am sure QML is great but I like QT to make cross-platform applications with native look for high-end desktops many cores.
I use QT (LGPL license) for the buttons, menus, ... while I do connect to many other 3rd party libraries to do computationally expensive video and image processing, rendering, networking, ... and I should admit QT is great for that the way it is right now.
C++ is a language that makes this possible, because it is a proper language and not a markup language.

Is all the complaining due to the fear that QWidgets won't be maintained and at some point QWidget-based apps won't work? Surely that's not going to happen, right?

opk: If main priority it's a Qt Quick, then I fear what bugs in QWidgets has been fixed very slow or not fixed at all in some cases.

I'm worrying of the native widgets future too. QML is good for designers, but its disaster in terms of performance especially on mobile platforms :( you said, there is no whistles in QWidgets? ok, then create widgets, based on QGraphics* like the libmeegotouch does. add there animation and so on
another problem with QML - very poor language. There is no eve ifdef's like facility. To make QML multiplatform I have to create qml code for each platform! this is ridiculous!
qt componets is another sad story: they are in early stage right now, they are incompatible on different platforms, there is foggy desktop status

@dashesy ""QT to make cross-platform applications with native look for high-end desktops many cores. C++ is a language that makes this possible, because it is a proper language and not a markup language.""

I use C++ and Qt also for this, I would like to use C++11 with lambdas with Qt, imagine the awesome of that. Javascript is garbage compare to that.

@vladest,
Im very worry too, QtQuick is not even complete and all the steam is in that side, Qt Widgets as people call it me I call it "Qt C++" have all the features already done should be maintained in parallel to QtQuick but really I dont know any designer that will use Qt or QtQuick, the designers are using Photoshop with Adobe Tools or HTML/CSS, etc. I work with a designer, I showed him QtQuick syntax but he told me forget it that is programming I'll need to go to programming school, I said to him no its just javascript he told me forget it give me html/css, photoshop etc . So even designers can't use or do javascipt and C++ developers find javascript to scripty or weak so where are we all of us heading with this nonsense of QtQuick as I said give me back my C++/Qt its all what a C++ programmer wants and as someone said for mobile its much better to use native C++ for performance, with javascript and virtual enviroments you will kill the device.

Qt is used mostly by C++ programmers around the globe.

The fastest mobile application environment now is iOS. Everything is fast and butter-smooth, on hardware with less MHz than Android phones. Is that because iOS SDK is 100% natively-compiled Obj C with 0% of lousy javascript?

Everybody loved the "beautiful"Web OS, but at the same time everybody complained about it's sluggishness. Is that because it's SDK was based on java script that you Nokia guys love so much?

I forgot to mention. In iOS SDK you can animate GUI. With no javascript, just natively compiled Obj-C. Surprise! Did you know that?

Anyway, I have abandoned the idea of using Qt for mobile development when the death of Symbian and Maemo were announced. I need Qt for only desktop programming, like thousands of other Qt fans. Hopefully the open governance model will bring some life back to the desktop part of Qt. Otherwise just forget Qt.

@serkol: You do know that Objective-C on iOS runs in a virtual machine, right? In any case, QML running on SceneGraph (Qt5) is equally butter-smooth on iOS... ;)

Please don't focus all to mobile devices. Otherwise desktop get obsolete,
like it seems at the moment.

For example, we need a Grid handle big amount of data for business processes.
With more features, easier handling of Widget's in it without need of
delegate anything.
Grouping of items, filters, header and footer lines, summary lines,
splitter, subqueries, aso.
Like XCeed for .net does or more.
But no development in QT here...

Other Question: Have the QML-development made any changes to the existing QTableView, QWidget, QStyle or whatever?
We don't like to test our C++ / QT Applications again, because QML code have influence to the behaviour.

SumWon@ I'm programming for iOS since 2008 and I can tell you that Obj C has nothing to do with virtual machines. The Obj C code is compiled during development by XCode, not during runtime. Compiled into native machine code, not into pcode - the same way as C++ is compiled into machine code. Obj C uses late binding and run-time type info. Modern C++ goes into the same direction, but that has nothing to do with virtual machine.

Regarding Qt5 - I'm glad to hear that. I will try it when it reaches release candidate, mot sooner, because unfortunatelly I don't hava time for alpha and beta versions. I don't think that I will try QML though, I cannot fond a use for it in my desktop app.

I think it's fantastic that we have so many enthusiastic members of the community who are concerned about the direction of Qt. I would encourage those of you who are willing to help, to get into #qt-labs on Freenode, and maybe discuss with Lars and between yourselves which parts of the Qt Widgets code you would each like to provide support for, and organise your passion and enthusiasm into effort which will benefit the entire Qt community. No part of Qt will want for patches and active development so long as there are people who are willing to put in the time and effort to maintain it; and judging from the comments on this blog post alone, it looks like there is no shortage of people who will be clamouring to be contributors in the open governance activity! Qt Rocks!

@Chris Adams: There surely is some people wanting to help, but most of us just want to use qt, not develop it.
About the issue, If the performance is good enough, qml is not bad, I think that it's the same overhead to learn to draw guis in c++ than to learn qml. As in c++ you still have to learn properties, values, and that stuff, the only difference, is a bit of javascript, but I think it's the best language for the task.

You can choose to use as little or as much javascript as you like in your QML app. QML and c++ play together nicely. We've been using it in this hybrid fashion in a medium-sized mobile app and it has worked out pretty well so far. QML for the user interface and the app data model and logic in c++. There's nothing inherently slow with QML, unless you do dumb stuff like run expensive javascript routines during each animation frame. Really looking forward to Qt5 and SceneGraph. I would say that it's somewhat odd to criticize something if you haven't even used it yet. Once you master QML (it doesn't take that long) I think you'll become addicted. It's not the right tool for every job, but then again what is? The only real complaint I have is the lack of mature built-in ui components ... writing your own buttons and combo-boxes and whatnot gets old after a while.

I cant understand the refusal of QML and the hype of the Qt Widgets. The QtWidgets are very unflexible. Take the Itemviews for example. It is very hard to costomize the look of the Itemviews to your needs. You have to reimplement the Delegate paint method and that can be very hard. For example try to make a interactive slider in a delegate it is nearly impossible. (You cant use setItemWidget() for that if you have many items and the doc says it does not work for non static content)

As I worked with QML such things are a cakewalk. As far as I cen see QML is far more flexible then QtWidgets.

Count me in the QML-skeptic camp. It seems like a solution looking a problem.

@João Barbosa Just how often do you really see animation in OSX and iOS applications? Probably as not as much as you think. It's very easy to over-use animation and it can get annoying fast. If Qt++ didn't have an animation engine you might have a point but it does and it works very, very well.

Also QML is missing basic elements like tree views so I can only see it being used for the most trivial of applications.

@hunt0r There's no rule that says you MUST use Qt's MVC system. We use the widget views and custom paint events and we haven't had any real issues. I'm not sure what the 'non-static' warning is about.

I would really like to see more effort put into the core C++ system. There are many, many bugs particularly on Mac and with tablet/touchscreen devices (eg. QTBUG-6127 which was raised back in 09) and some of the core tools like qmake or Designer could use some work, despite being in 'status done'.

Listen to your developers! Most of us use C++ Qt on the desktop and the tools that haven't been significantly updated in years. That's not going to change no-matter how hard to spin the QtQuick CoolAid.

C++ is a thriving language, especially with 0x around the corner, and Qt has always realized that power. Don't throw it away trying to play catch-up to Apple and iOS.

@Chris Adams:
Qt's development is a great concern for many developers, it affects our lives and dictates how we plan our development in the future. It is the one toolkit to use, if one develops in C++. There are decent others, but Qt is in it's own class.

I know that many wish to contribute to the project at some point, but it is not child's play, it takes time to get familiar with such a system at source level. One has to grow into it.

@hunt0r:
Like I said, it is really hard to discuss if people do not understand each others' needs.

Maybe you don't have any big implementation in your hands, done using widgets, using features that are far beyond the reach of QML at the moment? There are hundreds if not thousands of such projects, both commercial and open source. People who do such work do naturally feel resistant of reprogramming and reimplementing something that serves them right. Or even more, they do not want to change to a technology that hasn't matured yet and does not even provide them what they need. Bling is not a motivator that dictates desktop-programming, it is very conservative, you don't want to touch 20k or so tested and tried ui-code if there is no real reason. But I think widget users are not reluctant of trying features or goodies if it is provided :).

Another view is the simplicity and pure clean C++ that one gets with widget workflow. In a view of C++ programmer, QML looks really nasty with explicit geometry information baked into QML-files (it is possible to separate the "layout" and logic though, am I right?). Anyways, dependency to Javascript is in itself a big turnoff for C++-programmers, using the same language to program the application and ui makes many things straightforward.

There are many what if questions (more or less relevant :) )...like what if I had some fortran code that needs access to Qt....say I want to do some 2D graphics for printing from fortran routines? What if I am using IDE other from Qt Creator....is QML ui-programming fluent with Visual Studio (debugging etc)? How do the ui-bindings to other programming languages work....would it be possible to use Qt, say from Python, if QML were the only backend?

Many agree that there is some stiffness in widgets and redesign of some parts would be greeted. Still, what the framework provides for the developers is more than enough to balance that partial inconvenience out. In an overall sense of productivity and ease of use, widget framework gets a lot of love from desktop programmers around the globe.

@Danny The non static warning is about the setItemWidget() function not the Q(List/Tree/table) Widgets. Using setItemWidget() with more complex widgets you will get paint issues. And by overrinding the delegate paint method it is really hard to do non static content like a slider etc.
Btw. How can I NOT use the Qt MVC system? I can use the Q(List/Tree/table) Widgets yes but they are also backed up my the MVC system and use the same "View code"

@JubuluM Which futures does the QtWidget system provide that is so "far beyond the reach of QML"? What QML is missing is Widget set yes. But that will come I am sure without it QML would be useless on the Desktop.

You dont have to use explecit geometry Information in QML like in QtWidgets.
Moreover I think QML has a better layout system then the old QtWidgets (anchor based)

@hunt0r Delegating is not so easy. You can inherit from QItemDelegate, but if you want to copy the code from its paint method to your class there are some restriction. The private class of QItemDelegate are not accessible, the QD and QQ macro not works, and therefor the d-> or p-> (private members) are not accessible.

@hunt0r
Don't just blindly follow the books or the docs - you don't have to use the interview framework. You can create your own model observer or MVC classes. It's just a design pattern and it's not hard. Use the widget views and you own custom widgets to display your data and tie-in widget insertion, deletion and update with your own model system using signals or simple virtual interfaces.

Everyone time I've tried to use the Qt MVC system for something non trivial, it's gotten crazy complex with dozens of signals and subclasses required. Persistent indexes, paint delegates and proxy models are a lot of pain and unless you're displaying 1000k+ data items, the cost isn't worth it.

The only thing it really gives you is on-demand editors which saves you from having to manage the widgets. But if you want them to 'persist' in the view, you have to resort to faking them QStyle and ugly hacks.

And if your application is more than just simple tables or lists - perhaps you have graphics views or OpenGL contexts? - things get out of control. And adding Undo support is really, really difficult as well.

This is was a problem the whole NGViews were supposed to solve.

Great stuff and congratulations, but please please make the second sentence on the home page of qt-project.org explain what Qt is!! You never know who will come to the web site, you never get a second chance to make a first impression, and you are the marketing department for the project.

Nokia's site says "Qt is a cross-platform application and UI framework with APIs for C++ programming and Qt Quick for rapid UI creation." I would add "free and open source" and de-emphasize the details (as apparently any explanation will just inflame irritable Qt Widget users ;-) ).

skierpage: I want add a small improvement to your suggestion. If trolls place some good screenshots/tumbnails, with applications written with Qt, to home page it will attract more potential developers.

The nokia guys also said so for Meego just a few month ago, what happened then...

@Danny I know I can create my own MVC System but that shouldnt be the point of a framework. I mean I like the Qt MVC system because it is easy to make a filter with the QSortFilterProxyModel etc. The Underlying data structure is pretty felxiable and all.
But it is so hard to costumize the Views. And that is what QML solved for me because the delegate is just a item like all other QML elements and you can do everything in it. And unlike using a QWidget for every item it should work for many (1000k+) items. Btw. because you mentioned OpenGL you could even use a shader as delegete.

"But if you want them to 'persist' in the view, you have to resort to faking them QStyle and ugly hacks." Exactly that is what I am trying to say with QML that is pretty easy

You can also look at some other widgets like a slider for example. With QtWidgets it is impssobile to change the indicator to something costum. With QML the api could just allow you to set the indicator item and you can use whatever fancy indicator you like.

@SABROG:
Go to: http://qt.nokia.com/qt-in-use

You got, for example:
-Mathematica by Wolfram Research
-Google Earth
-Skype
-KDE
-Avogadro
...to begin with.

Also used companies like Lucas Films Ltd., Walt Disney Animation Studios, Next Limit Technologies, Sennheiser, DFS in their air traffic control system used in airport towers, etc. etc.

@hunt0r:

It is not just not all about QML widget set not being complete. But I'd say that things like graphics view framework with support for easy printing on a selected device, or file (pdf etc.), print preview, is important for some desktop programs. Creating and using main windows and using classes to add features like settings, network, threads, etc., etc. is really straightforward with widget qt. Like being said, of course many would greet if some things were redesigned even easier to use.

Other issues discussed earlier stlil remain. If these do not bother you, I understand. But for many projects they may be showstoppers.

JubiluM: of course it there, on qt.nokia.com and inside qt-in-use page. But i talk about place gallery to top of home page in qt-project.org and may be show random screenshot in 50% at full size.

Whatever you guys have said, the future of QT on mobile device is dead. It's not just about QML, but the whole QT. QT will be run on desktops only forever. Did you really know that?

Blue Sea: It's hard to see the future on this one, isn't it? One thing that indeed does change my perspective is seeing things from the other end of the pipeline. What do you choose if you want to develop across platforms on mobile today? Nothing! After all these years the world still hasn't provided a good answer to that question.

HTML5 - At the time of writing probably the only cross platform solution. They all seem to jump on the wagon. It makes sense, but what is not very pleasant is that they do so prematurely imho. HTML5 per se is ready, but what about a well-matured UI layer and by that I mean widgets and accompanying UI design tools. You can go with some form of half-baked jQuery based solution but none of them seem ready for prime time yet. Go commercial with Sencha Touch (I think it is no-cost, actually)? Some will opt not to. In either case you are leaving the familiar declarative HTML skillset somewhat to enter the realm of javascript APIs that are designed in a more or less haphazard way (as some will argue).

Flash - Adobe seems quite alone in pushing their platform to mobile devices. It may work well too - I have investigated but haven't been able to determine how smooth it works regarding access to all mobile interfaces and UI performance.

Qt - Officially not a cross-platform mobile toolkit. Unlike flash it is the native UI kit of at least one (dying) platform. Obviously Nokia cannot officially dedicate themselves to push Qt to competing platforms. But with lighthouse they do seem to make it easier to get at the very least the basic UI layer over to Android and iPhone. Time will tell if people like BogDan Vatra are successful in bringing the full Qt Mobility API over too (I frankly don't know the current state of android-qt-mobility etc).

Apart from that I don't know any mobile cross-device toolkits, but I'm no genius at discovering that stuff either.