Nokia announces start of Qt 5 development | Hacker News Reader

Nokia announces start of Qt 5 development

labs.qt.nokia.com

35 pointsguruz29 comments

    In Qt 5 the entry point for applications can be QML instead of C++.                                                                                                   
    We expect that all UI will be written in QML. JavaScript will become
    a first class citizen and we expect that a lot of application logic
    will be written in JS instead of C++.

This is very worrying. They are basically moving from being a tool to being a platform or a beast of that sort. They are going to adopt V8 too. It all shounds like they are trying very hard to be the next cool thing. In other words, they are building a totally different beast and risking they fanatic user base.

In the end, I'm under the impression that there's a brillant guy who has been recently hired and who is backed by the execs. That guy came to the office one morning with his 7 pages "technical" proposition (because the guy has a bit of technical background, y'a know) and said Qt was cool stuff but he had a vision for the app^Wproduct.

Or.. they are trying to kill Qt.

Oh, and I'm disappointed.

Qt has been a huge platform for some time now. It's what I call the Boost syndrome: if you want to use a small part of Qt, you have to shove your whole arm in the machine.

This should get better in Qt with the big modularisation effort that's happening.

QML is the logical progression for UI/UX design. Its going to make it easier to build innovative user interfaces and I fully believe you will still be able to build apps that look and feel just like the traditional QWidget based interfaces we have today. You can see this in some of the examples posted on the Qt Developer blog.

I lead the frontend development for a very large (and successful regardless of what the press says) command and control system. We completely decoupled our UI from our logic years ago into config files, and use QtScript for GUI events. This allows us to deploy on a large number of form factors with a single code base. Performance has not been effected as the logic is still C++. QML will be a huge improvement over that because it makes it so we don't have to manually build effects using QPainter, QGLWidget, or QGraphicsView.

I understand being resistant to change, but I am 100% behind them looking forward, building for the future, and not just assuming we will to continue doing things the way we do now.

I think it's a logical progression. In the future, all UI scripting will likely tend toward JS. After all, it's what the front-end devs know. It's easier to learn for 'artistic types' than C++, Web frontend devs know it, and ActionScript is also JS-ish these days.

Note though, that you don't have to use the scripting framework. You can define your GUI simply in C++ if you want.

Point of clarification: ActionScript and JavaScript are both dialects of ECMAScript.

Now, it isn't just that JS is easier to learn for 'artistic types', but it really is a quicker development process than traditional C++. My worry would be performance, just like everyone else. If you have already decided that a web application isn't good enough, why are you going to be okay with the JS penalty?

For the performance-critical parts you can still use C++. A web application does not allow that. Heck, as I said in my grandparent post, you can still use C++ for everything if "JS is not good enough".

Most people in the real world care about development turnover time. And as you say, developing in Javascript is a lot quicker than in C++, so why not write the non-performance-critical parts in JS?

Funny enough, I have written a piece of a web application in C, connected by JNI. It's even easier with CPython. Certainly, you can't do that with client-side JS, but could you imagine mixing desktop-side JS and C++ in the view?

That said, the piece that is in most need of performance in a desktop application is often the GUI itself. Imagine Microsoft Word taking a split second more when it updates the ribbon, for example.

Perhaps there is an exception for desktop apps that need direct connections to hardware.

Games have used scripting for GUIs forever. If performance is important somewhere it's in games. So I wouldn't be worried at all if it is used for "boring" desktop apps.

As long as the drawing is fast (which is the case, as it is handled by the GPU), it really doesn't matter in human time whether it takes 0.01ms or 0.001ms to react.

I like the latest iteration of qt and find writing code in qml very enjoyable for a beginner like me. What worries me is that there will be no official support for qt in windows phone 7 now that Symbian is heading to the grave.

Everything in this release says Qt/Embedded is dead and it's all about trying to stay relevant on smartphones. Small platforms need GUIs too, and there's just not enough MIPS on those platforms to handle QML and it's Javascript interpreter and all the other crap that goes with it. QML is a dog on anything below 700 MHz.

"Qt will require OpenGL (ES) 2.0 to work."

Sigh... Guess we're all using 4.7/4.8 forever.

I wouldn't write off Qt/Embedded just yet. Nokia has regularly made noises about their wish to eventually use Qt on Series 40.

Series 40 is their dumb-/featurephone OS. It powers most of the billion phones that Nokia sells yearly, and it's not set to be replaced by Windows Phone. There's no way OpenGL ES will make an appearance on those devices for a long while.

The Qt 5 announcement made a point of emphasizing maximum source compatibility between Qt 4 and 5. It seems likely to me that Qt 4 will still see some development from Nokia.

So you're going to try and run V8 on a Series 40 class processor? This is just getting silly.

Pavlov is clearly implying they must have plans not involving all that heavyweight stuff on low-end devices, not that they're going to just jam it on anyhow.

Yeah, that's it -- I guess my point was not very well articulated.

To be clear, I think Nokia is going to maintain an active branch of Qt 4.x for Series 40, and that work will benefit Embedded Linux as well.

I see a Qt fork coming that maintains the current approach for the future of the 4.x line.

They are moving to open governance. So, why not make use of it and let your voice be heard before going through the enormous effort that a fork will be?

Nah, how long will smartphones remain below 700MHz?

QT5 is planned for the future, it's not like it is released now. By the time it is ready, I don't think speed and OpenGL ES 2 support is still an issue on devices by then.

There are a lot of devices out there - billions, in fact - that are not smartphones. There are a lot of devices that USE Qt today and do not have graphic accelerators on them.

Qt's processor demands are happily keeping up with Moore's Law and the ability of new processors, leaving very little for the developers.

QT is trying to keep up with the state of the art in GUIs, which means flashy, animated, and a lot of eye-candy. This requires (relatively) heavy GPU power, hence the OpenGL requirement.

That's a choice they made. They expect that by the time when Qt5 is ready, all customer-facing devices will have a decent GPU.

"...by the time when Qt5 is ready, all customer-facing devices will have a decent GPU."

Not by a long shot. There are stacks and stacks of legacy designs that use Qt/Embedded and will never have a GPU on them.

Legacy designs should probably use a legacy version of Qt.

That's not an argument to keep Qt5 in the past forever. They rightly should look ahead instead of back.

I'm cool with that too, but then Nokia/Trolltech should say so. The current position is "well, embedded users can use Qt Lighthouse" which doesn't mean a thing at this point.

All the more reason to fork, as jsherer has noted right below this.

They are loosing the unixes too. This has always been a big winner for Qt. What toolkits run on most operating systems? There sure aren't many of them and they mostly suck.

I don't use Qt but at a glance QML sounds like XUL all over again to me, and we all know how great the UI's created with XUL are.

Been using QML for about 16 months, since it was in a development branch. I believe it has alot of potential for development of frontends and also I see it as a kind of a replacement of html which was created with static documents in mind, and then got aumented with other paradigms (css, javascript, dom, etc).

I feel the QML language is in a embrionary state yet, they are writing the use cases and writing the language at the same time, which will in time show some redundancies in the concepts they use now. Example: 1)there should be more (multiple) inheritance so that we could derive from QML elements like we do in OOP; 2) there was no ability to access the items ids like in a DOM tree.

But what sets a project IMHO is the ambition and the goals. And this team has both, and their work will deliver.

I haven't used XUL, but XAML on Microsoft platforms, and for that matter HTML, show that the basic concept can work very well. My biggest gripe with XAML is the heavy XML syntax, which it looks like QML ditches.

There is no implicit connection between the quality of the resulting user interface and the method you used to define it. If anything, having a nice concise, hierarchical way of defining a GUI should lead to better structured, more usable (uniformly spaced, resizable) interfaces than what you would normally get out of click-and-drop editors.

why?

Reply on news.ycombinator.com