Qt-contributors-summit-2014-QtCS14CrossPlatformManifestXmlInfoPlist
Cross-platform Manifest.xml / Info.plist
The goal is to have a common place to put information related to the application Info.plist/mainfest.xml, icon, orientation,… so that normally one can set it once for all platform.
Platform specific specialization should be possible.
A proposal was to use a command line tool that would have -platform xyz as argument, and it would look for a AppInfoXyz.qml if present and fall back to AppInfoBase.qml file.
The file would look like this:
Qml is already used in qt, and we already have good support for editing it (adding completions,…) but there were two important drawbacks highlighted:
1. Bootstrapping problems: it needs Qt on the host to be used
2. Too powerful: chance of misuse, and unmantainability
Still it was deemed ok for prototyping, so the content were discussed:
I was thought that it is better to begin with few properties and add them as requests come in.
For apple a reference of the keys for iOS is
The predefined winrt app manifest options are defined as qmake variables, and are listed here: http://doc.qt.io/qt-5/qmake-variable-reference.html#winrt-manifest
One could think to also add support for app store properties:
but this was skipped for now
Issues
Why not just unify the variables already supported by the existing qmake features?
- We want to support other build tools (CMake, qbs). OTOH, simple template variable replacement could be built into those tools as well.
How can we have a new build tool that relies on QML?
- Build this feature into qbs and only support this feature when using qbs
- Use JSON instead of QML (the Qt JSON classes are bootstrapped)
How do we add aribitrary values which show up in the manifest?
Like in the qmake variable approach, it would be good to make this flexible enough that arbitrary values can be added for variable replacement (this works easily for QML, simply add more properties). The proposal above has an arbitraryValues property, but a JavaScript object literal is less QML-esque than a list of properties. This way, we aren’t limited by the values in the base class or in need of an “arbitraryValues” property to catch everything.
How will we make the manifest generation flexible and avoid lots of code bloat in the generation tool?
We can use variable replacement (and perhaps a special syntax for loops) of a loose file template like used in qmake substitutes. That way, the tool itself doesn’t have hard-coded template parts that it generates from C++. If most manifests are XML-based, it might be worth supporting XSLT to perform more advanced variable replacement and transforms.