Qt-contributors-summit-2014-QtCS14CrossPlatformManifestXmlInfoPlist

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

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:

1. // AppInfoXyz.qml
2. AppInfoBase {
3.   arbitraryValues:({'UIStatusBarHidden':True})
4. }

1. // AppInfoBase.qml
2. import AppInfo 1.0
3. AppInfo {
4.     name: myApp
5.     description: "Nice and fancy app \
6. Really Qt!"
7.     longVersion: "1.2.2 ninja sloth"
8.     shortVersion: "1.2.2"
9.     organization: 'nice place inc.'
10.     identifier: 'net.place.nice.myApp'
11.     iconPrefix: 'myAppIcon'
12.     supportedOrientationsPhone: AppInfo.OrientationPortrait
13.     supportedOrientationsPad: AppInfo.OrientationPortrait
14. }

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:

1.     property string name // name of the application
2.     property string description
3.     property string longVersion
4.        // human readable version
5.     property string shortVersion
6.        // machine readable version
7.        //  only integers, points and dots, at most 3 fields (major, minor, patch)
8.        // Major version 0-65535, minor version 0-255, patch version 0-255,
9.        // on android 1.10.67 gets converted to 0x00010A43 (two hex digits per minor,patch, 4 for the major version)
10.        // 2 is converted to 0x00020000 for the versionCode
11.     property string organization
12.     property string identifier
13.        // unique identifier for the application, can use only [-a-zA-Z0-9.] and should be composed by
14.        // reverse domain name + '.' + normalized application name
15.     property string iconPrefix
16.        // prefix (possibly only the name prefix or even a directory) that is scanned for files used to create icons
17.        // this effectively looks at all the files matching iconPrefix+'*'  expecting them to follow the convention
18.        // iconName-height-width-dpi.extension From them the icons needed for the given platform are taken
19.        // rescaling the closest/ scalable ones if required.
20.     property string splashScreen
21.        // path to the splash screen
22.     property int initialOrientationPhone: AppInfo.OrientationAny
23.     property int initialOrientationPad: AppInfo.OrientationAny
24.     property int allowedOrientationsPhone: AppInfo.OrientationAny
25.     property int allowedOrientationsPad: AppInfo.OrientationAny
26.     property var arbitraryValues:({})
27.     property string nativeValuesPath

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

https://developer.apple.com/library/ios/documentation/general/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html

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:

1. property string longDescription
2. property list screenshots:[]

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.