さいきん試した Rust の GUI Toolkit 的な crate たちと日本語アプリでの実用性のメモ
現時点ではほぼダメです。試した中では唯一 conrod だけ日本語アプリを作る実用に耐えられそうです。
| crate | 日本語表示 | 日本語入力 | コピペ | UI部品の見栄え | その他 |
|---|---|---|---|---|---|
| conrod | ○TTF可 | ◎自然にできる | ◎自然にできる | ∞ 作り込み次第 | vulkan対応で軽快, GL版だともっさり気味 |
| druid | ◎システム可、TTF可 | ✘無理 | △事実上無理 | △ぼちぼち | フォント回りや2Dドロー回りはたぶん界隈では最強 |
| OrbTk | ○TTF可 | ✘無理 | ✘無理 | ○まあまあ | 開発は活発なので続けばよくなるかも |
| azul | ○システム可 | ✘無理 | ✘無理 | △ぼちぼち | exampleにも動作しない機能、壊れた機能が多い。開発が不活性化していて事実上終了かも |
日本語表示の(システム可)はシステムフォントを名前で指定すれば使えるものです。使えないものはフォントファイルをバイナリーで直接ロードする仕組みになっています。
conrod はもともとゲーム開発向けなせいかデフォルトの UI 部品の見栄え的にはとてもしょぼいです。一般的にゲームではUI部品の絵から作り込むため、デフォルトでリッチな見栄えのUI部品を実装するモチベーションは低いのだろうと思います。また、使う場合は vulkan 版が前提になると思います。 GL 版はハイエンド環境でも動作がもっそりめで体感で30FPSでてるか怪しい状態でした。 vulkan 版はとても軽快に動作し、60FPS基準のゲームでも作り込めそうです。
druid は開発のなかのひとがフォント系に強く、 GUI Toolkit として完成度の高いフォント回りの実装を依存 crate 群と併せて実現できています。特別にフォントを設定しなくてもOSのフォントからフォールバックも含め使用できるため、他のライブラリーと違い何もしなくても日本語環境で実行すれば日本語も表示できます。ただし、キーコードで直接打てる以外のテキスト処理の実装状況はまだまだで、日本語入力する手段がコピペを含めてありません。コピペの実装もいまのところ独特な仕様で example の多くのライブラリー内蔵の AppLauncher を介した実行形態ではアプリの内部構造の内側でのみコピー＆ペーストできる状態です。アプリの外とクリップボードを介してコピペ…できそうなPRはmergeされていましたが、 example の多くの AppLauncher を介した実行形態で使用できる状態になるのはまだ先の様子です。他の実行形態として druid-shell と呼ばれている実行形態と少量の example もありますが、このモードでは druid のほとんどの GUI 部品を使用できません。 開発はアクティブで、PRの対応もフレンドリー、ソースコードも綺麗で読みやすい方と思いましたので、 Authors のモチベーションが半年か1年か続けば化ける気はします。
OrbTk も開発のアクティビティーは良好で、ロゴデザインや UI 部品の意匠など良質な GUI Toolkit に育つかも…という期待はありますが、日本語入力やコピペはまだできず、こちらもあと1年くらい Authors のモチベーションが続けば…という気配です。
azul は今回検討対象を列挙した段階ではアーキテクチャーなど含め最良の選択肢の可能性を感じたものの…実際に試してみると未成熟というか…壊れてるというか…。 Authors のモチベーションまたは作業時間が既にほぼ無くなってしまっている気配が感じられるので、 fork が発展または Authors がヤルキを漲らせる様子が観測されなければこのまま錆びてしまうかも知れません。
ほか
今回の調査では非OSSなお仕事アプリでも使いやすい MIT, BSD系のライセンスに限り、Gtk, Qt のバインディングは除外しました。ライセンスに問題が無ければ、特にOSSでは素直に Gtk, Qt のバインディングを試すのが現状の開発途上な他のライブラリーに比べると圧倒的に苦労が少ないような気はします。
また、 Android 向けを主軸に iOS と Windows, OSX などのクロスプラットフォームに対応した flutter のバインディング flutter-rs も試そうとしましたが、日常的に Android, flutter での開発に触れ Dart もそこそこ現役で使えるマンじゃないと使用は難しそうです。少なくとも私は少々遊んだ程度では flutter のエコシステムをゼロから理解して最初のビルドが完了できるまでには至りませんでした。
ちなみに
アプリの生産性と実用性（ユーザー視点でのUIへのとっつきやすさ、ユーザーがUIへ要望する事の実現のし安さなど）という点では、 バックエンドに Rust を採用するにしても、一般的なアプリケーションを非OSSで開発する場合にエンドユーザーが触る部分の GUI としてのフロントエンド部分は Rust ではないなにかで開発し、バックエンド部分の Rust とはマーシャリングする構成がよいのではないかと思います。少なくとも現状で半年や1年以内にリリースするアプリを作りたいのなら。
GUIフロントエンド部分にボタンやテーブルやメニューのような一般的なビジネスアプリ的なUI部品が不要な場合は conrod でもいいでしょうし、 UE4 や Unity でも、あるいは C++ で Siv3D とかも良いかもしれません。
一般的なビジネスアプリ的なUI部品でまとめれば良い場合は、 electron 系と組み合わせてもいいでしょうし、JVM 系のテクノロジーと組み合わせ、あるいはプラットフォーム次第では .net core WPF 系も良い事もあるかもしれません。
一般的なビジネスアプリ的なUI部品も欲しいし、GPUレンダリングも欲しい場合は…どうしましょうね。 electron 系と組み合わせると GPU レンダー部分を WebGL2 や Three.js で制限されたり、描画コンテキストとUI配置の仕組みで苦労するかもしれません。WebGL制約を受けたくなければバックエンド側でオフラインレンダリングしてフロントエンド側へテクスチャーとして渡すようなトリッキーでオーバーヘッドの心配な方法が必要になるかもしれません。GPUレンダリングパワーの需要が大きい場合はフロントエンド部分をUE4やUnityと組み合わせ、3Dコンテキスト系のUI部品でも顧客が本当にほしかったアプリのUIを実現するのが現実的かもしれません。その場合はウィンドウの上の方のメニューと下の方のステータスバーのようなUIもUE4やUnityで作れないわけではありませんから…。Excelっぽいやつ出してとかは…もうそうなったら素直に別プロセスでQtで作ってIPCとかで…いいんじゃないですかね…😭
ある日とつぜんWSL2が起動しなくなったメモ
きょうもいちにち。Windows Terminalを起動…しない。正確にはメインウィンドウを出そうとする辺りまでは起動はしているようだけど、一瞬で消えてしまうので実質起動しない。
とりあえず cmd で wsl る:
WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel
と、いうわけで「このリンク」とやらを踏み、
"Windows Subsystem for Linux Update Setup" を install する。よくわからないが一瞬で終わる。
なんか知らんけど(†1) wsl が動くようになり、
Windows Terminal も起動するようになりました。
Microsoftのエラー時に示されるリンクが有用だっただけでも感動できる素晴らしいUX体験ですね。もちろん嫌味です。
参考
VSCode の extension にコマンドを追加する時に使わない方がよい文字のメモ
"category" に _ (アンダースコア文字) を入れてしまうと、実際に使う時にコマンドの絞り込みが期待動作しなくなって悲しい。
例: category を hoge_fuga として description を puyopuyo にすると…:
- CTRL+SHIFT+P して
>hgpとか>gapuとか入れてもコマンドが見つからなくなる hoge_fugaを最初から入れれば出てくるけれど、完全に入力したり、そもそもコマンドで_を省略せずに打鍵するのは高コストなので不便になる
という知見を得たのでメモを残しました。
category = hoge-fuga だと >hf のように - を省略してもコマンドの絞り込みから外れないので便利を維持できる。
-のほか、./#は同様に省略しても絞り込みで外れない区切り記号として使用できる
屋内撮影の照明のON/OFFに手スイッチ操作するよりOK,Googleできたら便利かなーって、スマート電球…ではなくてスマートプラグのやすいの買ってみたのです。のメモ
音声を出すのエネルギー使うにめんどくさいって思っていたのですが、すんごい便利でした…。
もの
買ってみたもの → VStarcam WIFIスマートプラグ スマートコンセント
お値段 = 1,499 円 (執筆時点; keepa価格推移↓)
届いたもの↓
専用アプリ tuya smart life と Google Home
箱や取扱説明書は紙質もよく日本語で表示されていますが、メーカー不明、その他いろいろ不明状態。取扱説明書もけっこーゆるふわ。たぶん技師属性持ちじゃないと扱えないかも。技師属性もちの人はたぶん簡単に扱えます。
懸念点として、専用アプリが .apk ぽん置きページへの誘導になっている事。箱や取扱説明書の QR を読むと Google Play とか Apple のそれじゃない謎のメーカーかどこか(ユーザーには箱や取扱説明書からはわからない…)の .apk ぽん置きウェブサイトへ飛びます。
飛びますのですが、ここでメーカーらしきところが "tuya" っぽい事がわかるので、野良 .apk はいやだーという事で Google Play で検索したらありました🙆♀️
と、いうわけで、
- tuya の smart life アプリを Google Play からインストールし、
- 取扱説明書に従ってスマートプラグの電源ボタンを5秒押し、
- アプリ右上のデバイスを追加するっぽいボタン → Auto Scan
- 設置場所の WiFi ネットワークの AP の接続情報を設定 (こわい<便利)
- スマートプラグに名前を付けて保存
するとアプリで on/off できるようになります。すごいべんり。応答もはやい。(LED電球とか繋ぐ照明も応答がはやい場合)
さらに、 Google の Home アプリをこの状態で起動すると自動的にデバイスを発見して画面の上の方に表示してくれています。表示をぽちって登録すると、
とかで音声操作できるようになります。べんり。 Google Home 経由だと応答はちょっともさる。音声認識からの応答としてはすごいはやいけどね。
ちなみに、スマートプラグに付ける名前を "light" とかにしておくと、 Google Home が照明らしい事を勝手に忖度してくれるようになり、
- 「おーけーぐっぐぅ、あかりつけて」
- 「おーけーぐっぐぅ、でんきつけて」
みたいな呼びかけにも期待動作してくれるようになります。
…すごい便利…。
WSL2 から X410 ( または vcxsrv など ) へ画面を投げる方法のメモ
WSL1 だと 127.0.0.1:0 で Windows ホスト側の X Server へ画面ぽーんできて楽でした。WSL2ではすこし手間がかかるようになりました。
X Client ( on WSL2 ) -> X Server ( X410 )
cat /etc/resolv.confで WSL2 (内側)から Windows ホスト(外側) へつながる IP を確認export DISPLAY=172.21.128.1:0などしてDISPLAY環境変数を設定- X410 の
Allow Public Accessを有効にする (vcxsrvなら-ac引数を有効にする ) konsoleなど起動して動作を確認する
自動設定されるように工夫
シェル起動時に実行される適当なところ ( ~/.zshrc とか) に以下を仕込む:
export DISPLAY="$(awk '/nameserver/ { print $2 }' < /etc/resolv.conf)":0
ちなみに WSL 以外の環境と ~/.zshrc 的なそれを共有したい場合は:
if [[ $(grep -i Microsoft /proc/version) ]]; then export DISPLAY="$(awk '/nameserver/ { print $2 }' < /etc/resolv.conf)":0 else export DISPLAY=127.0.0.1:0 fi
とかしておけば便利です。
参考
vscode: Terminal と Editor のアクティブを行ったり来たりトグルするキーの作り方のメモ
要求
キーは何でもよいのだけど、例えば
F7を押すと- ターミナルではない何か（エディターやエクスプローラーなど）がアクティブな状態なら → ターミナルをアクティブに
- ターミナルがアクティブな状態なら → エディターをアクティブに
- キーボードのフォーカスのアクティブターゲットがトグル
する便利な状態にしたい需要があったとします。私にはありました😏
実現する方法
Keyboard shortcutsを次のように2件ユーザー設定でカスタムします:
(1): ターミナルではない何か（エディターやエクスプローラーなど）がアクティブな状態なら → ターミナルをアクティブに
{ "key": "f7", "command": "workbench.action.terminal.focus" }
(2): ターミナルがアクティブな状態なら → エディターをアクティブに
{ "key": "f7", "command": "workbench.action.focusActiveEditorGroup", "when": "terminalFocus" }
Note: VSCode のキーボードショートカットの GUI 編集モードでも右クリックでコンテキストメニューを出せば When を入力できます。
これで、 F7 を押すとエディター（あるいは他のどこか）にキーボードの入力フォーカスがある状態ならターミナルがアクティブに、ターミナルがアクティブな状態ならエディターがアクティブにトグルしてくれるようになります。けっこー端末でコマンドばばばばばばばばって打ちたい派には、これが理想の便利状態なひとも、いるかもね👩🔧
おまけ: Terminal でのスクロールとキーボードショートカット
VSCodeのTerminalでのスクロールのデフォルトはAltを使うパターンになっていて、ふだん使うことの多い端末エミュレーター等とはキー操作が異なる場合もあると思います。例えば Windows Terminal だと CTRL+SHIFT+↑/↓ なので VSCode でも Terminal を頻繁に使うひとは、ついでに合わせておくと便利かもしれません。
{ "key": "ctrl+shift+down", "command": "workbench.action.terminal.scrollDown", "when": "terminalFocus" }
{ "key": "ctrl+shift+up", "command": "workbench.action.terminal.scrollUp", "when": "terminalFocus" }
眠くても、疲れていても、ひゅーまんがミスしにくい環境がよいです👩🔧
Olympus OM-D E-M1 Mark Ⅲ が Mark Ⅱ からの更新ユーザーとしては悲しすぎたので書き留めておくメモ。 Mark Ⅳ があってももう事前情報を好意的には見てはあげません。
OLYMPUS OM-D E-M1 Mark Ⅲ が初めてのフラッグシップモデル級のカメラ購入で、 OLYMPUS のサンプルを他社と比較して SPEC を確認した上で購入するなら…悪い製品ではありません。ただ、MarkⅡの時と違い、2020年現在では基本性能を上げてきた他社に対してセンサー、基本の解像度、動画性能などで足踏み状態なので良い選択肢としてオススメできるかは…やや人を選ぶ要求次第かもしれません。防塵防滴、7.5段手ブレ補正、TruePicⅨの基本性能と画像として取り出せる絵のピクセルレベルでの解像感の良さ、MFTでレンズ含めの携行性が非常に良くM.ZUIKOレンズも良い…そういった基本的な部分で選択するのは良いと思います。
これから書くこの記事の本体の悲しみのメモはその上で、特に Mark Ⅱ から Mark Ⅲ へメーカーの事前情報を好意的に信じ期待して高いお金を払って更新したユーザーの悲しみどころのメモです。もちろん、事前情報の確認が足りないだけと言ってしまえばそういう部分もありますが、2020年のフラッグシップモデルですしね…、カメラ本体の公式サイトに書いてある事は好意的に読んで期待したいじゃないですか…特に本体性能の数値的にはまるで進化がなかったので、それ以外での進化はけっこう頑張っているはずだ…って。
1. WiFi アクセスポイント経由で Olympus Capture と接続できるよ！
但し、 「接続中に本体を操作して撮影すると画像がPCへ自動コピーされる別モードでの接続ができるだけ」でした。Olympus Captureはリモートコントロールソフトです。接続できるって書いてあったらリモートコントロールできると思うじゃないですか…。できません。
プレビューしても遅延が数百ミリ秒発生してしまう、とかあるんでしょーけど、ユーザー的には遅延1秒でもコントロールさせて欲しいです。フォーカスとシャッターの制御しかできなくてもさせて欲しいです。本体でシャッター押した画像が転送されてくるだけとか完全にただのおまけ機能じゃないですか…。WiFi接続では画像転送しかできないのに、USB接続と同じような扱いに見える具合で対応しましたって言っちゃってるの、ダメだと思います。
小さく注意書きはあったのかな…。Captureの機能からは別モードというかおまけ程度の機能過ぎると思うのです。ゆえに、それにユーザーが期待してしまわない程度にはきちんと表示しておいてほしかったです。
Ⅲへの更新の期待の1/3はここでした。WiFiではCaptureからコントロールできないって、がっかりでした。
…そもそも O.I. Share ではアドホックモードのみで簡易的であれカメラコントロールできてるじゃないですか…。アクセスポイント経由の遅延に何か拘りがあるのかわかりませんが、ユーザーが本当にほしかったものを考えろです。
2. Bluetooth でスマフォと接続できるよ！
但し、「WiFiで接続可能な場合は従来どおりスマフォアプリが全自動で現在のWiFiを切断してアドホックにカメラのWiFiと接続するけどね！」でした。事実上 O.I. Share に Mark Ⅱ までのユーザーが期待した Mark Ⅲ でのBluetooth接続はできません。ⅢのWiFi/Bluetooth接続をONにすると、 O.I. Share は常に WiFi のアドホック接続を試みてしまうので WiFi 切り替えが従来通り発生してやぼったい、うざったいです。
では、 Bluetooth はいつどこで接続できるのかと言うと、カメラの電源をOFFにした時にバックグラウンド接続という形で使用できる、という事のようです。カメラを電源OFFにした状態でも Bluetooth の設定が済んでいれば O.I. Share からカメラの電源はOFF（という体裁でBTと一部の機能がバッテリーを消費して動作するモードでONになっている）のまま、写真の取り込みをできます。カメラの電源はOFFという体裁の接続モードなのでカメラの撮影関連のコントロールはできませんん。
カメラの電源をONにしている状態で再生モードでRECボタンでチェックを付け、OKボタンを押してメニューからシェア予約しておくと、電源OFFになった後、スマフォの O.I. Share が Bluetooth でこっそり接続し、シェア予約された画像をスマフォ側へ自動的に取り込んでくれる、という機能が主体のようです。実際これは便利なので、期待した動作とは異なりますが、若干救われたお気持ちです。
電源ON時もBluetoothだけで接続して欲しい…。PCのCaptureともBluetooth接続できて欲しい…。ユーザーが本当にほしかったものをよく考えてほしい。
3. USB PD で給電できるよ！
但し、「USBケーブルをつないだだけでは自動的に給電開始されずUSBの動作モード選択をぽちぽちしてPDを選ばないとならないし、そもそもPD対応ではない給電元からは給電一切受けないけどね！」という仕様みたい。
先ずね、USBケーブルが挿されたら、PDでも非PDでもプロファイルに応じた給電を受けなさいよ…と。PDもわざわざケーブルを挿した後で「どのモードにする？」とかメニューをぽちぽちユーザーに操作させずに自動的に給電受けて下さいよ…。めんどくさいよ…。そもそも、挿したUSB元がPDではなくても可能な電力量の給電をしきい値を設けるであれ受けて欲しー。悲しい。
ちなみにPD対応ではないが給電能力は十分なUSB元に接続してメニューぽちぽちでPDを選ぶと「しばらくお待ちください」表示になり固まります。(USBケーブルを抜けば復帰します)
ユーザーが本当にほしかったものを考えてほしい。ただでさえ数値的には本体性能上がらず Mark Ⅲ への更新には否定的なレビューも多かった今回の新型です。せめて数値的にあがっていない部分の4年分の更新を、できれば「これができるようになったよ！」と言うのなら、それを言われたユーザーが期待するであろう、対応の文言に釣られたユーザーが本当に期待したものを実現して欲しい。
4. 手持ちハイレゾ50MP！
(ご注意 この項は初稿では↑までのⅡ→Ⅲユーザーの期待感による優良誤認の悲しみから「手持ちハイレゾ50MP役に立たない」と勢いよく言い切ってしまいましたが、夜の屋内の白熱電球照明での試写で撮影条件としてはやや厳し目だった事もあり、後日、改めて楽しめないか試写＆画像比較付きで追加メモを書こうと思います。)
いちおう撮影はできます。できますが、手持ちハイレゾは役に立ちませんでした。
両肘をテーブルに置いて軽く固定を意識した状態で手持ちハイレゾ撮影しても、ふつーに非ハイレゾで撮影した方がブレないだけ綺麗です。手持ちハイレゾでもよくブレを押さえて超解像してくれていると、技術的にはとても関心できる絵ができあがります。しかし、そもそもハイレゾにせず1枚だけ撮影した方が綺麗に撮れます。手持ちハイレゾの意味なし。
もちろんピクセルレベルに近い確認をすれば、という程度ですし、三脚モードにして静的な絵なら80MPで撮影できる点ではとても嬉しいハイテック機能ではあるのですが、手持ちハイレゾは実用性の無い釣り針だった事には代わりありません。
ちなみに三脚ハイレゾモードにしつつ手持ちで80MP撮影しても、手持ちハイレゾモードにしつつ50MP撮影しても、非ハイレゾシングルフレームの15.9MP撮影と比べると大差ないブレ度の絵が撮れます。そういうわけで、すごいのだけど、手持ちハイレゾが無意味だった事には代わりありません。
…ムキムキマッチョ筋肉人間三脚ゴッドハンド＆ボディーをお持ちのよく訓練されたスーパープロフェッショナルカメラパーソンならあるいは…。まあ、素直に三脚ハイレゾしましょうという事ですね。
その他
ジョイスティックが増えた事について
付いている意味がほとんど無い気がする程度の機能性でした。十字より斜めを入力しやすいとは言え、器用にカーソリングするには小さすぎ＆硬すぎです。そもそもタッチスクリーンもあるので器用にフォーカス位置を替えたりしたいユーザーはジョイスティックよりタッチスクリーン使えばいいですね。基本的にジョイスティックと十字の操作は同じ処理が割り当てられている事もあり、なおのこと要らないですね。
代わりにタクタイルスイッチを1つ増やしてくれた方がよっっっっっっぽど嬉しかった程度の謎の何かであったことがわかりました。一応PSやXBOXのゲームパッドのアナログスティックのように押し込みボタンとしても使えるのですが、方向入力に化け易く、素直にタクタイルスイッチを1つ付けてくれた方が嬉しいです。
MENUが左上へ行った事について
キャンセルボタンを兼ねているので、OK/CANCELを右手だけで操作できなくなりました。地味に不便。INFOが右下になった事はこれは便利なので、やっぱりジョイスティック要らないのでは感がマシマシに…。
褒めるところはないのですか？
あります。たいていは Mark Ⅱと変わっていないか、本質的には大差ない部分は良いカメラです。冒頭に書いた防塵防滴などなど。
ただ、数値で比較する基本性能が X-T4 はじめ圧倒的に負けてしまっていて、センサーサイズもMFTのデメリット（メリットも大きいけれど）を抱えつつお値段はそれら競合と大差ない、それでⅡからⅢへの変更点がほとんど実質的に微妙な程度だったのですから、信じてⅡからⅢへの更新を予約購入で行ったファンとしては悲しみです。
TruePicⅧからⅨへの更新は気持ち動作のキビキビ感は向上したような気もしますが、実感としては気の所為程度です。メニューが少しだけわかりやすく工夫されたとか地味な更新もありますが、Ⅱでもファームウェア更新で追従できた程度の事のような部分もあります。
少なくとも予約購入した事は過ちでした。もっとよく確認していればⅡからⅢへの更新はしなかったか、X-T4を買っていたかもしれませんし、Nikonへ帰っていたかもしれません。せめて、発売前情報で期待した「あれができる」「これができる」との釣り針を見たユーザーが想像した本当にほしかった機能を着実に実装してくれていたら、数値的な基本性能は変わらなくともⅢにしてよかった！ってついーと＆メモを残していたと、思うのですけどね…。
なんだか、悲しい。
まあ…基本性能は…気に入っているからこれを使う事に悲しみを懐き続けるとか、X-T4にしておけばよかったと未練を何年も引きずって生きる事になる、という事はないのですが、予約購入したOM-D E-M1シリーズのファンとしては、更新にかけた期待を裏切られた悲しみはメモを残す程度にはありました。ダメですね、ファンというか、信者になってしまっては。次からはNikonからOlympusへ主力カメラを替えた時のように、しっかり吟味して更新していきたいと思います。
