QMultimedia and the move to QtMobility
I would like one of the trolls to address the move of QMultimedia to QtMobility.
In v4.7 the QMultimedia classes are there but the discussion has been that, going forward, support for QMultimedia will be in the QtMobility project.
Does this mean that the QMultimedia classes will not be in the framework SDK in future releases? Or if the classes stay but the support moves to mobility will this require both to develop using the QMultimedia classes?
This question comes because of the lack of back-end support for phonon and a much poorer development environment in phonon and (as yet) only a few native back-end pieces vs QMultimedia. I acknowledge that QMultimedia involves more than just sound but QMutimedia is much richer where cross-platform desktop development for soundcard centered applications are concerned.
Perhaps this is a somewhat uninformed question, but at the risk of showing my ignorance I ask those who know anyway.
It’s really a fairly simple, but pervasive problem with QtMobility: Naming. It has very little do do with mobility as in “mobile phones” and everything to do with, well, abstracting all kinds of functionality… From the description of the module: “These APIs give the developer a range of desirable functions for a mobile platform, but now these functions become possible on platforms not traditionally associated with some of the features.” Read more over here [doc.qt.nokia.com] :)
I read that when it came out. It does not address the support question. If QMultimedia classes are going to continue to be included in the base SDK, will it also be necessary to have the Qt Mobility latest to be complete (support wise)?
The whole diversion to QtMobility is somewhat confusing in both name and concept since we are talking about a substantial amount of functional overlap between desktop and mobile applications for most of the module.
So which do I use going forward to ensure that the future support will be there? Do I use the classes included in the SDK or do I download and install the QtMobility package and use those classes? And which offer the most desktop flexibility in terms of interfacing with desktop hardware?
While I applaud the effort to make Qt more broad based, the dispersion of essential functionality to other projects (like mobility) has not been very well documented (at least where I can find it – can you say SDK documentation?) and is still very unclear in my mind.
In my feeble mind it would seem more rational to keep the basis and majority of functionality for sound and video in the SDK with full functionality and application for desktop application, and add to that (in separately maintained and used add-on projects like mobility -or whatever they are going to call products for meego, symbian, and others) that do sound and video very differently.
This approach was taken with Visual Studio integration vs. QtCreator, and it has worked out pretty nice. Not sure about the move to VC++ yet because I am not a fan of nor consistent user of Microsoft products, including Windows.
Of course, I don’t make such decisions.