Qt-contributors-summit-2014-QtCS14CrossPlatformManifestXmlInfoPlist

From Qt Wiki
Revision as of 13:25, 23 August 2015 by AutoSpider (talk | contribs) (Simplify punctuation)
Jump to navigation Jump to search
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.