Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

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

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
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.

Revision as of 14:02, 24 February 2015