つまり、添付のREADMEファイル（ src / plugins / platforms / uikit / qt-lighthouse repository branchにあります）のすべての指示に注意深く従えば、iOS用のQt （シミュレーターとおよびデバイス用）、標準的な例からいくつかのQt Quickアプリケーションを起動します。 これはiOSの実際のポートではなく、公式のサポートや公式のステータスはないという事実に注意を促します。 Qt APIの多くの部分は、正常にアセンブルされた部分（アセンブルできなかった部分は言うまでもなく）でも機能しない可能性があります。
一般に、このR＆Dプロジェクトの目標は、iPhoneでいくつかのQMLアプリケーションを起動して、このベンチャーの一般的な可能性をテストすることでした。 そしてもちろん、QMLテクノロジーの素晴らしさを示すために。
Qtのアセンブリとリンク
それは最も疲れる部分でしたが、最初は非常に失望しました。 いくつかの命令が利用できないという事実に関連するコンパイラエラーから始まり、関数や変数の値が実行時に突然変更されるかゼロにリセットされるという事実で終わる、非常に多くの問題に遭遇しました。 その結果、ポピーのgccの基本的なmkspec（Qtビルド設定ファイル）には、Mac OSのデスクトップバージョンの環境固有の値が含まれていることがわかりました。 当然、これはiOSツールチェーンの頭脳を爆破しました。 その後、mkspecの環境変数を多少正しいものに調整しました。 iOSは基本的にPOSIXプラットフォームであるという事実により、ほとんどすべてがすぐに機能しました。
Qt Lighthouse Platformプラグイン
最も簡単な方法を選択し、Cocoaプラグインと同じことを行いました。UIView（より正確にはCALayer）でバックストアQImageをblitしました。 明らかに、これは最良の解決策ではありません（QML flickrデモを実行する場合、肉眼では顕著ではありません）が、この解決策は「R＆Dプロジェクト」の概念と一致しています。 まだいくつかの問題がありましたが。 たとえば、イベントキューハンドラー（QEventLoop）の統合中に、イベントの処理中に制御が特定の時間枠内にアプリケーションのメインサイクルに転送されなかった場合、システムはiOSアプリケーションを強制終了しました。
レンダリングの適切なソリューションは、OpenGLサーフェスをQtのバックストアとして使用することです。 その後、すべてのレンダリングがこの表面で行われます。 UIKitでは、このサーフェスを、対応するUIViewのCALayerのバッファーとして提示します。 このようにして、Qtが描画する共通のビデオバッファーが取得され、UIKit iOSサブシステムが「ネイティブ」と認識され、階層全体でotrsirovatされます。
結果
LighthouseはiOS上で動作できます（少なくとも小さなパッチを適用した後）。QMLは非常に優れたテクノロジーです:-)。 さて、Lighthouseにとって便利なプラグインであることに加えて、少なくとも非常に有益な経験であることは注目に値します。
以下にビデオデモをいくつか示します。
iOSのQt Mobility-加速度計は、空間の深さをエミュレートするために使用されます。
QMLインターフェース：
QGraphicScene
いくつかの営利団体がこの移植版のリリースを取り上げ、QtでiOS向けの商用ソリューションを作成できるLighthouseプラグインを（金銭的ではありますが）世界に紹介したいと思っています。 これにより、「コーディングを減らし、作成を増やし、あらゆる場所に展開する」というスローガンが再び確認され、強化されます。