Nokia Announces Qt 5 Plans

aloniv writes "Since Nokia announced its switch to Windows Phone 7, people have been worried about the future of Qt. Well, it turns out Nokia is still going full steam ahead with Qt, having just announced their plans for Qt 5. Some major changes are afoot code- and functionality-wise, but the biggest change is that Qt 5 will be developed out in the open from day one (unlike Qt 4). There will be no distinction between a Nokia developer or third-party developer."

Comments

translation....

[metalmaster]

"There will be no distinction between a Nokia developer or third-party developer." becomes "Develop it yourselves you lazy bastards, but dont forget to put our name on it too"

Re:translation....

[Anonymous Coward]

"There will be no distinction between a Nokia developer or third-party developer."

Which will be a disapointment for any Nokia developers hoping to get paid.

Re:translation....

[suy]

"There will be no distinction between a Nokia developer or third-party developer." becomes "Develop it yourselves you lazy bastards, but dont forget to put our name on it too"

Very wrong. Look at the list of maturity and status of Qt modules. Nokia still is ready to maintain a huge percentage of Qt. They simply deprecated stuff because they think that other alternatives are better (eg. ditch Phonon because there is QtMultimedia). The only piece that Nokia is not interested in maintaining and that the comunity is worried about, is QtSVG, because the alternative, the SVG support in Webkit, is considered too big/slow, or unsuitable for being LGPL only.

This is Qt development frameworks (aka "old Trolltech") being honest in what they are interested about.

Oh, and being even more open in how they develop (they already have public BTS and reports).

Re:This will kill KDE

[karper]

It's going to be a behind-the-scenes change and it's not as big a deal as the kde3kde4 change. Reference: http://aseigo.blogspot.com/2011/05/relax.html

Re:KDE5

[Randle_Revar]

KDE5 will not break the world like KDE4 did. Just as Qt5 will not break the world.

http://aseigo.blogspot.com/2011/05/relax.html
http://aseigo.blogspot.com/2011/05/qt5-kde5.html

Re:Ugh....

[Entrope]

I came from a Gtk+ background, but am using Qt Quick (QML) in one project. The widget set as of Qt 4.7.2 is woefully anemic, but other than that, it seems like a general improvement over using C++ for the entire UI. At least 90% of user interfaces (averaged over the world's applications; there are a few very graphics-intense apps that bring down the average) do not need the marginal speed improvement you can get by using C++ instead of QML. Qt does a pretty decent job at making it easy to go between native C++ widgets and QML code, so C++ developers get to focus on the parts of the GUI that need performance.

What is in using QML for me? I get to offload most of the GUI development to a UX designer who is better at that sort of thing (and costs my employer less per hour of work). Then I get to focus on the novel and application-specific parts of the interface. I also get cleaner separation between those application-specific bits and the overall skin.

Re:Best GUI library for C++

[Timmmm]

> The only way to do it right is to use the native controls, which QT DOES NOT.

I think you have not used Qt for a long time...

http://en.wikipedia.org/wiki/Qt_(framework)#Use_of_native_UI-rendering_APIs

Re:QT5 should drop MOC and adhere to standards

[tibit]

C++ simply does not provide the introspection needed for a major application development framework. If it did, you could drop MOC. The way it stands, moc basically generates introspection tables because the out-of-touch [expletive deleted] folks who design C++ couldn't be bothered. That's my take on it.

Every time you interface C++ code with any sort of an interpreted or JIT-ed language, you have to generate "bindings" using an external tool precisely because C++ lacks facilities for code to know about other code. Qt folks were nice enough to maintain such a tool themselves and to make it a core part of their process. I don't consider it a bad thing. QMetaObject system makes it fairly easy to expose QObjects to any other language that's either interpreted or JIT-ed.