Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Harmattan Meego 1.2 vs. Symbian^3
Alicemirror last edited by
I have a compatibility question. using the Qt-Quick 4.7.3 (or the next beta 4.8) the qml documents can be set to run with very few differences on both Harmattan Meego 1.2 (formerly N9 devices) and Symbian^3 devices. These differences are related to some QML elements os propterties of some elements that the documentation explicitly note for meego only.
As a matter of fact, to usew the new Qt-Quick comopnents features like page navigation based on stack or toolbar, screen properties and generally the new Qt-Quick compnents you should import the component themselves.
But there is a different import working on Symbian or Meego, with two different names. In the case of symbian the import should be
@import com.nokia.symbian 1.0@
else for meego
@import com.nokia.meego 1.0@
Thus the same Qml documents that work for Symbian^3 devices when set to be compiles for Meego need the redefinition of all the imports or there is a way to manage the conditional inclusion ? I am thinking to a solution that involves the Loader elements but I am not sure and seems not so simple.
Someone knows if there is a right method ?
chriadam last edited by
I believe that at the moment, conditional imports are only supported via using the loader - see http://bugreports.qt.nokia.com/browse/QTBUG-16854 for more information. However, I think this is an issue that will be considered further (perhaps as part of the Qt Components project, or perhaps in QML core) as it is a common concern.
Alicemirror last edited by
Many thnaks, Chris.
At this point - this is what I supposed, the bug note you cite are very clear - I can isolate the components that can be conditionally included in a set of sources instead of another. Is there a way with the recenv Qt 4.7.3 to decide in the main.cpp whati s the hardware platform so the program can conditionally run starting from a mainSymbian.qml instead of a mainHarmattan.qml document? If this is so, this maybe a workaround that works.
At this point there should be only one main duplicated because all the others are managed by the main with loaderds and inline writtern QML. Thus the physical qml files have any import but a piece of code that import the correct components depending by the startup setting.
Best is if it is possible to launch che main qdclatrative QML document with a parameter (automatically identificed from main.cpp) that instructs all the files what is the piece of code to be written.
I hope I was sufficiently clear. In few workd the question is if it isp ossible to create a logic like the following:
- main.cpp check for the architecture
- main.cpp launch qdeclarative main.qml with a parameters (or in some way main.qml as when starts a parameter to the main.cpp program)
- depending by this parameter main.qml set a flag that is passed as property to all the modules that write a inline piece of qml on top of the code importing the correct qml component.
Many thnks for your support.