|
|
| Line 1: |
Line 1: |
| =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.<br /> 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<br /> 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
| |
|
| |
| 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:<br />
| |
|
| |
| 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). <span class="caps">OTOH</span>, simple template variable replacement could be built into those tools as well.
| |
|
| |
| ===How can we have a new build tool that relies on <span class="caps">QML</span>?===
| |
|
| |
| * Build this feature into qbs and only support this feature when using qbs
| |
| * Use <span class="caps">JSON</span> instead of <span class="caps">QML</span> (the Qt <span class="caps">JSON</span> 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 <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?===
| |
|
| |
| 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.
| |