QT5 is a dream come true, and when it becomes omni-deployable (android, ios, raspberry pi) it will be even better.
QT5 is a dream come true, and when it becomes omni-deployable (android, ios, raspberry pi) it will be even better.
For people doing lower-end embedded stuff Qt5 isn't going to give you much, if you can run it at all.
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.
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.
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.
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.