Qt-contributors-summit-2014-QtCS14CrossPlatformManifestXmlInfoPlist: Difference between revisions
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 | 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 | 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:
- // AppInfoXyz.qml
- AppInfoBase {
- arbitraryValues:({'UIStatusBarHidden':True})
- }
- // AppInfoBase.qml
- import AppInfo 1.0
- AppInfo {
- name: myApp
- description: "Nice and fancy app \
- Really Qt!"
- longVersion: "1.2.2 ninja sloth"
- shortVersion: "1.2.2"
- organization: 'nice place inc.'
- identifier: 'net.place.nice.myApp'
- iconPrefix: 'myAppIcon'
- supportedOrientationsPhone: AppInfo.OrientationPortrait
- supportedOrientationsPad: AppInfo.OrientationPortrait
- }
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:
- property string name // name of the application
- property string description
- property string longVersion
- // human readable version
- property string shortVersion
- // machine readable version
- // only integers, points and dots, at most 3 fields (major, minor, patch)
- // Major version 0-65535, minor version 0-255, patch version 0-255,
- // on android 1.10.67 gets converted to 0x00010A43 (two hex digits per minor,patch, 4 for the major version)
- // 2 is converted to 0x00020000 for the versionCode
- property string organization
- property string identifier
- // unique identifier for the application, can use only [-a-zA-Z0-9.] and should be composed by
- // reverse domain name + '.' + normalized application name
- property string iconPrefix
- // prefix (possibly only the name prefix or even a directory) that is scanned for files used to create icons
- // this effectively looks at all the files matching iconPrefix+'*' expecting them to follow the convention
- // iconName-height-width-dpi.extension From them the icons needed for the given platform are taken
- // rescaling the closest/ scalable ones if required.
- property string splashScreen
- // path to the splash screen
- property int initialOrientationPhone: AppInfo.OrientationAny
- property int initialOrientationPad: AppInfo.OrientationAny
- property int allowedOrientationsPhone: AppInfo.OrientationAny
- property int allowedOrientationsPad: AppInfo.OrientationAny
- property var arbitraryValues:({})
- 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
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:
- property string longDescription
- 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.