開発環境で悩む #
この１年間、サボっていたわけではない。CatShanty3を何で作るか。色々考えて、色々試してみた。 C++、C#、Go、Python …。試したと言っても、レベルの低い私ゆえウィンドウを出してコンニチハ世界くらいなのだが。
で、実際C++が最強だとは思う。ActiveBasicはBasicの革を被ったCなどと言われているし、CatShanty2プラグイン等はソース公開に当たりActiveBasicでは役に立つまいとC++で書き直したためまるっきり経験がない訳でもないし、一応Windows上では何でもできる事になっている言語だし。1
しかしこの老いぼれにはもうポインタを追いかけ回す気力も、掘り下げたC++テクニックを学ぶ気力も無い。
言語選定 #
さて、CatShanty2でメモリの確保と開放と（開放のし忘れも）を繰り返すうち、こんなん欲しいなと思っていたのがRustだった。導入も簡単で、CatShanty2のモノアイコン変換ツールなどで感触を得た経験があることから、とりあえずRustを前提に構成を考えてみることにした。
そこかしこでRustは難しい言語と書かれている。実際掘り下げれば難しいのだろうが、ガベージコレクションのある言語のほうが私には理解が難しく感じる。
どうせ私なぞRustの上っ面しか触らないで組むだろうし、掘り下げたRustテクニックにはそもそも着いていけそうにないため、BacicやC感覚で使うと開き直ればそう難しくはなさそうだ。「Rustの無駄遣い」とか叩かれそうではあるが…。
未来のある言語であることは誰も異論がないだろう。言語の死の心配が相当年数必要なさそうな事も安心材料のひとつだ。
一方不安材料が無いわけでもない。Rustは基本UTF8で構成されるためWindowsの標準であるUTF16上では面倒が起こる可能性がある。特にファイルパスがUTF16にしかない文字で作成されていたりすると面倒なことになりそうだ。基本あまりないだろうがユーザーの行動は予測できない。正確に処理できなければルールを作るなどこれは追々考えることにする。
画面表示とSQLite3との連携はUTF8で問題なかろうと考えている。
GUIツールキット #
今どきの言語はGUI周りが切り離されている。いや昔からそうだけど選択肢が増えたゆえにデフォルトが無くなったという感じだろうか。
ポトペタできるGUIツール付きの言語も少なくなり「もしかして直にCreateWindowとかもしなくなるん？」…とおじさんは膝から崩れ落ちた。
そういった意味では C#＋WindowsForm はポトペタが非常に魅力的だったが、基本となるC#の長い構文を覚えられそうになく、またWindowsFormも業務向け以外どう生き残るのかという記事を読むうち不安になり見送ることにした。
いつも最後にはIMEが… #
Rustも基本的にGUIを描画する機能は搭載しておらず、GUIが欲しければ何らかのツールキットと組み合わせてウィンドウを表示することになる。
GUIツールキットは多種多様で、それぞれに得手不得手があり使用目的によって選定する感じのようだ。
どのGUIツールも良いな～素敵だな～♪と思い試したが、最終的にはIMEとの連携具合が芳しくなく、見送ってしまう結果となる。
IMEに丸っきり未対応だったり、インラインで表示されずIMEの窓だけがあさっての場所に出てきたりと、海外ソフトでよく見るあの状態が軒並み起こってしまう。IMEはソフトとOSの間に割って入るため必要のない国の人には全く必要なく、対応も後手に回るようだ。
日本語フォントも大事 #
例えばRust＋SDL2には心躍った。
一応IMEも考慮されており、IMEの割り込み中を判断できるため開発者が根性で入力中のインライン描画で対応することが可能だ。
しかし今度は日本語の表示が今ひとつという問題にぶち当たった。
ゲームエンジンゆえテキストも基本的にフレームごとにレンダリングされるのだが、大量のテキストは工夫をしないと重くなってしまう。それに加えて折返しの問題も出てきた。テキストの矩形範囲は一応指定できるものの、日本語での折返しは実用にならず、結局は表示の高速化と共に一文字ずつプログラマブルに描画する必要があると感じた。
更にテキストエリアのスクロールなども加わえることになれば、もうCatShanty3を作るのかSDL2用の日本語周りを作るのか比重がわからなくなってきそうだった。フォント自体をEXEに埋め込むという仕様も芳しくなく、気に入ってはいたものの私のレベルではやはり見送ることとした。
TAURIと出会う #
WebView #
確実にIMEが動作するツールキットは解っていた。WebViewを採用したGUIツールキットだ。WebViewなら表示はブラウザエンジンになるため、恐らくツールキット開発チーム自身それと気にすることなく実行環境でIMEが自然に使える結果になるだろう。
しかしWebViewなら「Electronでいいんじゃね？」と、また言語の選定に逆戻りしてしまう。
私はjavascriptにも自信がなく（ぉぃ、脆弱性うんぬんの記事を読むと更に自信がなくなる。
開発者レベルが低いのだよ…。
それは「Rust＋WebView」でも同じことであり、javascriptもセキュリティ問題も出てくる。それに私がWebViewを物色していた頃はRust用のWebView GUIツールキットはあまりなく、開発停止したものがいくつか見つかるくらいだった。
TAURI #
そんな中、TAURIがβ版となった。
TAURIは以前からそれがGUIツールキットであるとは知っていたが、基本技術も理解できずサンプルも動かすことができず、ただただテリー伊藤似のチェアマンをタウリー伊藤と勝手に呼んで覚えていた。
お世辞にもチュートリアルもそれほど充実しておらず、それがなんの役に立つかわからないAPIドキュメントと、散らばったいくつかのサンプルプログラムがドキュメント内やGithubなどから手に入る状態だった。
β版となり、どうやらTAURIがWebview2のGUIツールキットであるという事をようやっと理解した。このあたりは私の別ブログに感想がまとめてある。
WebView2は基本的にはWebViewと同じようにブラウザのレンダリングエンジンを利用したものだが、その提供方法が違うという。
WebView #
WebView(1)はElectron等にみられるように実行ファイル（コンパイルされた制作物）へブラウザエンジンを丸ごと含めてしまう。
メリットは同じバージョンの実行ファイルであれば同じブラウザエンジンが入っているため、それによる動作の差異が無いこと。
デメリットはブラウザエンジンがバージョンアップされても実行ファイルを再コンパイル再リリースしない限り古いままとなることで、特にセキュリティアップデートに係る場合に開発者の責任負担となってしまう。
WebView2 #
対してWebView2はランタイムとして提供する形を取れば、コンパイルされた実行ファイルにブラウザエンジンを含めずに済む。
当然デメリットもありユーザーは別途WebView2ランタイムのインストールが必要となる。
しかしメリットも大きく、例えばWindows向けに提供されている WebView2 Evergreen ランタイムは一度インストールしてしまえば最新の状態が自動で保たれるらしい（WindowsUpdateの対象になるのだろうか？）。 またWindows11になれば最初から内蔵されており、ユーザーはランタイムのインストールすら必要がないという。ブラウザエンジンを含まないためコンパイルされた実行ファイルが Electron に比べ非常に小さくなるというのもメリットだ。
だが正直なところWebViewは躊躇している。
前述の通りjavascriptやセキュリティもそうなのだが、フロントエンドとバックエンドで通信する方式は、ネット越しであればWebページとサーバーの関係と割り切れる。しかし同一マシン上で同じことをするというのは、直ぐそこの相手に手紙を書いているみたいでどうも好きになれない。
が、いつまで悩んでいても仕方がないので、とりあえず Windowsターゲット且つ、Rust＋TAURI にて模索してみることにした。
-
現在ではユニバーサルアプリなども色々制限は取っ払われたらしいが。 ↩︎