Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

People from hacker news, check out qtquick or QML, it's like html but without the legacy and the bad parts, just powerful syntax for developing apps, and thanks to network transparency QML can be downloaded from the web also.

QT5 is a dream come true, and when it becomes omni-deployable (android, ios, raspberry pi) it will be even better.



Qml is much better than html, thanks for anchors, transitions between states, animation and etc. One remaining thing I just waiting for fully usable version of desktop components.


Is it something like XAML?


QML is nice, but make sure you have the processor overhead for it. It's all javascript and the interpreter will suck up your processor time.

For people doing lower-end embedded stuff Qt5 isn't going to give you much, if you can run it at all.


Qt5's QML2 is using V8 as the JS engine and an opengl es2 scenegraph, so it's actually quite fast. Depending on your embedded platform, you should still be able to achieve pretty impressive performance.


Um, okay. Can you point me to a MIPS implementation of V8 that runs well on a 360 MHz R1 architecture? Oh and my CPU doesn't have any hardware OpenGLES acceleration. How should I work on that?


fortunately or unfortunately the future will require all gui capable computers to have hardware accelerated graphics. To compensate for bad drivers there will be fallbacks to somewhat fast software rasterizers like llvmpipe.


>Um, okay. Can you point me to a MIPS implementation of V8 that runs well on a 360 MHz R1 architecture?

Umm, okay, can you point to anyone that mentioned that Qt5/V8 would be good for those chips? It's not like anyone came in the thread writing that "Oh, QT5 javascript scripting would be great for my 360 MHZ R1".

Oh and my CPU doesn't have any hardware OpenGLES acceleration. How should I work on that?

You shouldn't and nobody said you should. Just like nobody said it would be fine to program Big Blue with, or Arduino.


Depends what you call "lower-end embedded". Even on a mildly modern ARM SoC like the Freescale iMX series, QML works very well, and the OpenGL acceleration makes for an incredibly smooth UI. Also, the backend is still C++, and any computationally intensive tasks should be done there.


Well yes and no.

Sure, you will take a runtime performance hit if you do a QML UI because all the QML needs to be parsed.

But then again, no it's not all javascript and no it will not suck up all of your CPU. When you write simple bindings (for example someProperty: otherPropert ? "yes.png" : "no.png") the QML engine actually detects these simple cases and doesn't invoke the javascript interpreter when it needs to evaluate the expression, but handles it internally instead. Also if you don't want to do things in javascript you really don't have to as calling QObject slots is super easy. If you stick to simple bindings and write your logic in C++, the javascript interpreter won't have much to do.


>QML is nice, but make sure you have the processor overhead for it. It's all javascript and the interpreter will suck up your processor time.

What professor overhead? It's 2012. Our quad core processors sit idle most of the time -- and even those in our phones aren't particularly challenged.

Plus, what "interpreter"?

For one, V8 uses JIT, second, it's way faster than Ruby/Python (languages that are also used for app development), and in Qt5 V8 is just the logic layer, the GUI/scene-graph parts are C++ and accelerated.

For people doing lower-end embedded stuff Qt5 isn't going to give you much, if you can run it at all.

Well, DUH! Who said anything about them? These people can't even afford to use Java or C#, much less V8 bindings for a UI toolkit, and even the C++ Qt5 part is not targeted to them anyway.


"and even the C++ Qt5 part is not targeted to them anyway."

Thanks for reinforcing my point. Qt5 is more of a smartphone platform than a GUI toolkit for embedded systems now. There are still a lot of low-end chips that need graphics toolkits and the new whizbang stuff just can't work on these systems. Don't tell me QML2 is great for prototyping GUIs when I can't even run it on my platform.

I completely understand why the switch in focus came along, especially when Nokia took over. I still have bug reports from 2-3 years ago that have been marked "don't care, won't fix" by Nokia. My anecdata comes from actual years of experience making Qt work smoothly on lower-end hardware.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: