[クロス本草稿]未調査の項目

# 未調査の項目

本章は、クロスプラットホーム・デスクトップアプリケーションについて、わたしが使ったことのないテクノロジーについて書いている。
なので、他の章よりさらに現実乖離度が高いと思われる。
個人的な印象であることに留意しつつ、短く留めるよう努力する。

## その他のクロスプラットホームFW

クロスプラットホーム・アプリケーションFWはGTK/Qt/Electronだけではない。
ぱっと思いつくものとして、Java,C#,Unity,SPAがある。(これらがFWであるかはともかく)

### Java
JavaはGUIなデスクトップアプリケーションだけのものではないが。
joel氏が「宇宙人が見様見真似で作ったため味を付け忘れたUI、後に修正されたが」と語っていた奴。
<<joelonsoftware本へのリンク>>
Javaの機能は、クロスプラットホームGUIだけでない。

Javaの悪評について。
Javaが使われている環境ではプログラマの扱いが悪いという話が目につくし、Java自体も酷評されている印象がある。
特に恨みもないので擁護するようなことを書いておくことにする。
COBOLを置き換えて長期利用する安定したシステムにJavaが採用されるのは、エコシステムを含めたJava全体で見ればそのようなメリットがあるということだと思う。
Javaが持つ機能は、GC・VM・中間表現その他、当時から見たらどれも革新的な新テクノロジだったと思う。
Javaはそれらの新テクノロジを一度に商用システムに持ち込み一般化したすごいパイオニアだった。
そしてJavaは、商用化についてパイオニアになった。
同時に、パイオニアが犯すことを避けられないあらゆる失敗を抱え込んだのではないかと思う。
悪いことに、Javaは成功した本物の商用言語製品だった。後方互換性を捨てることはできないことは失敗を修正する機会がなかったことも意味する。
長生きすればするほど、Javaは10年前のよく知られた言語設計の失敗を今もそのまま抱えた言語として、悪評も固めていったのではないかと思う。

と、個人的にJava開発環境を悪く思ってはいないが、前述の通りプログラマには劣悪環境であるという話しか聞かない。
個人開発で採用する理由はないし、Java案件に関わらないで済ますためにも、Javaは使いたくない。

### C#
フォームデザイナとかあってすごく使いやすいJavaのようなものらしい。
Linuxでやるのが面倒くさそうなので採用したことはない。

### Unity
ゲーム用。
Qtと同じくモバイルアプリケーションを守備範囲に含む。
ユリアーモの文字割り当て変換(※)のWebサービスを作っていた時、競合がWebサービスをUnityでラップして、デスクトップアプリケーション版をリリースした。
[自家のWebサービス sisto_converter]( https://github.com/MichinariNukazawa/sisto_converter )
[競合のWebサービス EsperantoToJuliamoWithHTML5]( https://sugurunatsuno.github.io/EsperantoToJuliamoWithHTML5/ )
[競合のアプリケーション EsperantoToJuliamo]( https://twitter.com/fuyunosuguru/status/903929591122636800 )
モバイルやゲーム以外にも、Electronと同じ使い方で同じ範囲をカバーできるらしい。
Unityは言語として、C#とJavaScriptが使える。他にもあった気がする。

個人的には、Qtと同じくモバイルアプリケーションに傾注するであろうという予想とか、プロプライエタリであり無償版は起動時ロゴが出る、3D性能が必要なことはしない等の理由で、マルチプラットフォーム・デスクトップアプリケーションFW選択の際に真っ先に脱落する。

※
ユリアーモは「ことのはアムリラート」劇中に登場する架空の自然言語。
独自のアルファベットを用いる特徴があり、公式からフォントがリリースされている。
[『ことのはアムリラート』ユリアーモフォント配布 公式URL]( http://sukerasparo.com/sp004/font.html )
このフォントのアルファベットの割り当てが特殊であるため、一般に使われるラテン・アルファベットの割り当てを、公式の独自割り当てに変換するサービスが必要となる。

### Webアプリケーション（SPA等)
デスクトップアプリケーションから主役の座を奪い、現在はモバイルアプリケーションと覇権を争っている奴。
滅茶苦茶雑に言えば、ブラウザがあれば動くので、マルチプラットフォーム性が最強。
現実にはいろいろ面倒なところや弱点があり、決定打とはいえない。（このへん列挙は面倒だし、読者を含め私より詳しい人はいくらでもいるので書かない）

ぱっと作れてぱっと使う、家の外やモバイルで使う、軽いツールを作る場合はWebアプリとして実装することが多い。
前述の、ユリアーモの文字割り当て変換は軽いツールの例。

## 使用していないFWの機能

GTKは機能ヘルパ兼依存ライブラリの数が多く、Qtは分厚く範囲の広いクロスプラットホームレイヤであるためこちらも機能が多い。
Electronはわりと機能の少ない小さなアプリケーションを書いたつもりなので、最低限以上の機能は使わないようにしていた。
そのため、筆者が使用していない機能のほうがずっと多い。
そもそも網羅的な入門書を書くのではなく、本物のアプリケーションを書くためにGTK,Qt,Electronを使っているので、全機能を触っておく必要はない...。
(なので本書はこういう感じです。)

というわけで、使っていない機能の話はしておくべきかと思うので本章を書いた。

### Electron:自動アップデート・クラッシュレポート
githubのリリースページにインストーラを置いておくと勝手に認識して自動アップデートしてくれる、とかだと嬉しかったのだが、そういうわけでもない模様。
そもそもElectronを使って作ったlina_dictoはプラットフォーム毎にインストーラを作るのが面倒でzipでリリースしている。
現在はインストーラ形式での配布はしていないので、自動アップデートの前にインストーラ作成しなければ。

クラッシュレポートはJoel先生のブログ記事を読んでからぜひ実装したい機能で、Electronに搭載されていると聞いたときは狂喜乱舞したのだが、いかんせん作ったアプリケーションのユーザベースが少なすぎてコストに見合う気がしない...。

### Qt:QML
JSでアプリケーションを書くなら普通にブラウザアプリのほうがいいと思う...。

### Qt:Android/iOSのモバイルクロス開発
Androidアプリのリリース経験があるが、[lina_dicto for Android]( https://github.com/MichinariNukazawa/lina_dicto_for_android )はElectronで書いたlina_dictoをWebViewで移植して作ったので、QtのAndroid,iOSクロス開発機能は使用しなかった。
QtのAPIがカバーする範囲はよくわからないが、QtのAPIに無い機能については、プラットフォーム毎にネイティブコードを書くし、そういう書き方ができる、とのこと。
<取り消し線>Qtでモバイル開発していた周囲の人々は、iOS11対応で悲鳴を上げていた。</取り消し線>

### Qt:組み込み
死に体のデスクトップアプリケーションからQtが見つけ出した脱出先。
セットトップボックス等でHTMLが重いような場合を想定しているとのこと。
ターゲットによってはQt自体のクロスビルドから自前でする必要がある。
組み込みQtのサポートは販売ライセンスがデスクトップアプリケーション版と異なるという話が。

### GTK:マークアップ言語によるウィンドウ構造記述
QtはQtCreatorをフォームデザイナとしてポトペタするのが一番簡単であるためそれを使うことになるし、目diffを目patchする羽目にでも陥らない限りはQtのXMLを直接触る必要はない。
ElectronはHTMLを書くしかないので、マークアップを使う使わないという話にそもそもならない。
GTKの場合、QtCreator相当のフォームデザイナがクラッシュするような品質であり、マークアップを直接書くのはドキュメントが整備されていたとしても御免こうむるので、コードで直接UIを構築していた。
今はもう少しマシになっているといいなと思う。Windows版はバイナリ配布が無いかもしれないけれど。

### GTK/Qt:非ネイティブな言語バインディング
バインディング境界でバグが発生したら解決できなさそうだったので、生産性を犠牲にして、GTK,Qtではネイティブ言語なC言語,C++言語をそのまま使う選択をした。
また、バインディングはどうしてもネイティブ言語よりドキュメントの優先度が低く、ユーザが少ないこともあって、情報を集めることが難しい。
既にバインディングを使ってアプリケーションを書いてしまった場合や、公式が本当に一級市民扱いのサポートをしている場合以外には、おすすめしない。