Embedded project. Wait for -QT- Qt 5?
-
Hi all,
Just joined up but have been looking at -QT- Qt for a while. I've especially been paying close attention to the development of -QT- Qt5. I'm looking at starting an embedded project in the next couple of months and am very interesting in the features that will be available with 5. Specifically, the animations and (hopefully) quicker development for interface stuff provided via -QT- QtQuick 2. From what I understand with 5 you'll be able to do much more in with Quick 2 and it will be fully graphics accelerated provided you have supported hardware (ARM in this case).I guess what I need to know is if this is a bad idea? I don't generally target such new API's but it seems like -QT- Qt5 really introduces some nice features for my use case. I'm not opposed to C++ but if the other will allow quicker development then it seems like a good deal. It does seem like v5 dates keep slipping, however, so I wonder if I should target 4.8 instead. Thoughts?
Edit: it is spelled Qt, not QT; Andre
-
Since there's no love lost between QML/QtQuick and myself I can't speak from experience here, but when you think it would be beneficial for your use case, as you say, why not just start developing with Qt5 now? The source code of Qt5 is available, or am I mistaken? And when Qt5 finally is released, you either have a halfway finished application already or at least enough experience with Qt5 to decide whether QML etc. is the right tool for you.
-
Usually developing with very new programs could be tricky, especially if they have bugs and if they do, you can't really do much about it.
I suggest you inform yourself and see if you can do it with -QT- Qt 4.8, and then port it on -QT- Qt 5, as there should be full backwards compatibility, so you could just take care of the interface with the enhanced capabilities of -QT- Qt 5
-
Keep in mind Qt5's main advantage - Qt Quick 2 REQUIRES OpenGL, which may or may not be present in embedded environments. Most ARM based SoCs do feature OpenGL ES support.
Plus you will have to wait at least a few more months before Qt 5 is final, and there is no point of waiting, especially since you seem to be focused on QML, and Qt Quick 1 will sort of be "forward compatible" with Qt Quick 2, you won't have all that much problem migrating to Qt Quick 2 later on.
-
Yeah, my hesitation on starting was the bugs present in the current version of five. I guess I could just compile the latest which I'm assuming is close to beta code unless things are way behind.
Yeah, the ARM architecture I'm targeting will have OpenGL ES. The fluid graphics are actually a pretty important thing so I had hoped, and thought I had read, that it was present within the embedded environment of Qt as well. Can anyone clarify on this? That would throw a wrench in my plans a bit.
Does the current version 4.8 embedded support graphics acceleration on ARM platforms with OpenGL ES?
Thanks for all your help. I tried for weeks to just research stuff but finally decided to just ask the community and I'm glad I did.
-
I think you can get OpenGL acceleration with 4.8, but not for QML, you will have to do your gui with QtGui, gl painting and gl widget, the states and animation APIs - everything by "hand", which is not really hard, but somewhat tedious due to the lack of a modern, gl centered GUI API, which kind of defeats the purpose. There was plenty of noise about the lack of it "a few months ago":http://qt-project.org/forums/viewthread/16465/
I supposed you will be targeting embedded Linux, the only other wide spread alternative for ARM is Android, which is not all that well supported, and in the case of Linux, one can only speculate the quality of gl driver implementation.
-
Yeah great point on the linux support (yes it is linux). I've been playing with the gumstix as an initial platform. The opengl support is there in the form of blobs but haven't yet tested how good it is. I'm assuming it won't require an major graphics processing power to run Qt, but certainly needs a solid driver.
