Qt-contributors-summit-2014-QtCS14CrossPlatformManifestXmlInfoPlist: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
m (Categorize)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
[[Category:QtCS2014]]
=Cross-platform Manifest.xml / Info.plist=
=Cross-platform Manifest.xml / Info.plist=


Line 6: Line 8:


The file would look like this:
The file would look like this:
<div class="cpp-qt geshi">
# <div class="de1"><span class="co1">// AppInfoXyz.qml</span></div>
# <div class="de1">AppInfoBase <span class="br0">{</span></div>
# <div class="de1">  arbitraryValues<span class="sy0">:</span><span class="br0">(</span><span class="br0">{</span><span class="st0">'UIStatusBarHidden'</span><span class="sy0">:</span>True<span class="br0">}</span><span class="br0">)</span></div>
# <div class="de1"><span class="br0">}</span></div>
</div>
<div class="cpp-qt geshi">
# <div class="de1"><span class="co1">// AppInfoBase.qml</span></div>
# <div class="de1">import AppInfo <span class="nu16">1.0</span></div>
# <div class="de1">AppInfo <span class="br0">{</span></div>
# <div class="de1">    name<span class="sy0">:</span> myApp</div>
# <div class="de2">    description<span class="sy0">:</span> <span class="st0">"Nice and fancy app <span class="es1">\</span></span></div>
# <div class="de1">Really Qt!"</div>
# <div class="de1">    longVersion<span class="sy0">:</span> <span class="st0">"1.2.2 ninja sloth"</span></div>
# <div class="de1">    shortVersion<span class="sy0">:</span> <span class="st0">"1.2.2"</span></div>
# <div class="de1">    organization<span class="sy0">:</span> <span class="st0">'nice place inc.'</span></div>
# <div class="de2">    identifier<span class="sy0">:</span> <span class="st0">'net.place.nice.myApp'</span></div>
# <div class="de1">    iconPrefix<span class="sy0">:</span> <span class="st0">'myAppIcon'</span></div>
# <div class="de1">    supportedOrientationsPhone<span class="sy0">:</span> AppInfo.<span class="me1">OrientationPortrait</span></div>
# <div class="de1">    supportedOrientationsPad<span class="sy0">:</span> AppInfo.<span class="me1">OrientationPortrait</span></div>
# <div class="de1"><span class="br0">}</span></div>
</div>


Qml is already used in qt, and we already have good support for editing it (adding completions,…) but there were two important drawbacks highlighted:
Qml is already used in qt, and we already have good support for editing it (adding completions,…) but there were two important drawbacks highlighted:
Line 12: Line 42:


Still it was deemed ok for prototyping, so the content were discussed:
Still it was deemed ok for prototyping, so the content were discussed:
<div class="cpp-qt geshi">
# <div class="de1">    property string name <span class="co1">// name of the application</span></div>
# <div class="de1">    property string description</div>
# <div class="de1">    property string longVersion</div>
# <div class="de1">       <span class="co1">// human readable version</span></div>
# <div class="de2">    property string shortVersion</div>
# <div class="de1">       <span class="co1">// machine readable version</span></div>
# <div class="de1">       <span class="co1">//  only integers, points and dots, at most 3 fields (major, minor, patch)</span></div>
# <div class="de1">       <span class="co1">// Major version 0-65535, minor version 0-255, patch version 0-255,</span></div>
# <div class="de1">       <span class="co1">// on android 1.10.67 gets converted to 0x00010A43 (two hex digits per minor,patch, 4 for the major version)</span></div>
# <div class="de2">       <span class="co1">// 2 is converted to 0x00020000 for the versionCode</span></div>
# <div class="de1">    property string organization</div>
# <div class="de1">    property string identifier</div>
# <div class="de1">       <span class="co1">// unique identifier for the application, can use only [-a-zA-Z0-9.] and should be composed by</span></div>
# <div class="de1">       <span class="co1">// reverse domain name + '.' + normalized application name</span></div>
# <div class="de2">    property string iconPrefix</div>
# <div class="de1">       <span class="co1">// prefix (possibly only the name prefix or even a directory) that is scanned for files used to create icons</span></div>
# <div class="de1">       <span class="co1">// this effectively looks at all the files matching iconPrefix+'*'  expecting them to follow the convention</span></div>
# <div class="de1">       <span class="co1">// iconName-height-width-dpi.extension From them the icons needed for the given platform are taken</span></div>
# <div class="de1">       <span class="co1">// rescaling the closest/ scalable ones if required.</span></div>
# <div class="de2">    property string splashScreen</div>
# <div class="de1">       <span class="co1">// path to the splash screen</span></div>
# <div class="de1">    property <span class="kw4">int</span> initialOrientationPhone<span class="sy0">:</span> AppInfo.<span class="me1">OrientationAny</span></div>
# <div class="de1">    property <span class="kw4">int</span> initialOrientationPad<span class="sy0">:</span> AppInfo.<span class="me1">OrientationAny</span></div>
# <div class="de1">    property <span class="kw4">int</span> allowedOrientationsPhone<span class="sy0">:</span> AppInfo.<span class="me1">OrientationAny</span></div>
# <div class="de2">    property <span class="kw4">int</span> allowedOrientationsPad<span class="sy0">:</span> AppInfo.<span class="me1">OrientationAny</span></div>
# <div class="de1">    property var arbitraryValues<span class="sy0">:</span><span class="br0">(</span><span class="br0">{</span><span class="br0">}</span><span class="br0">)</span></div>
# <div class="de1">    property string nativeValuesPath</div>
</div>


I was thought that it is better to begin with few properties and add them as requests come in.
I was thought that it is better to begin with few properties and add them as requests come in.
Line 22: Line 84:


One could think to also add support for app store properties:<br />
One could think to also add support for app store properties:<br />
<div class="cpp-qt geshi">
# <div class="de1">property string longDescription</div>
# <div class="de1">property list screenshots<span class="sy0">:</span><span class="br0">[</span><span class="br0">]</span></div>
</div>


but this was skipped for now
but this was skipped for now
Line 38: Line 107:
===How do we add aribitrary values which show up in the manifest?===
===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 <span class="caps">QML</span>, simply add more properties). The proposal above has an arbitraryValues property, but a JavaScript object literal is less <span class="caps">QML</span>-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.
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 <span class="caps">QML</span>, simply add more properties). The proposal above has an arbitraryValues property, but a JavaScript object literal is less <span class="caps">QML</span>-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?===
===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 <span class="caps">XML</span>-based, it might be worth supporting <span class="caps">XSLT</span> to perform more advanced variable replacement and transforms.
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 <span class="caps">XML</span>-based, it might be worth supporting <span class="caps">XSLT</span> to perform more advanced variable replacement and transforms.

Latest revision as of 17:46, 6 January 2017

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.