エンジニアTA向けGUIチュートリアルとしてのファイルエクスプローラ実装。
そろそろPySideをちゃんと覚えようと思ってファイルエクスプローラをつくってみた。
これ個人的に GUI ネタとしてはわりといいかんじだと思ってるのでざっくり紹介してみる。エクスプローラっていろんなGUIネタが詰まってるから、チュートリアルとしてはたぶんすごくちょうどいい。
というわけで以下、ファイルエクスプローラをつくるのに扱う主な GUI 要素を羅列してみる。リンク先はすべて PySide 関連。
- その他
さて、まぁこれだけ使えれば基本的な GUI 構築で困ることはあまりないと思う。とはいえ TA 界隈、いわゆるアーティスト（デザイナ）でも人によってはこのくらいふつうに扱えてしまうので、エンジニアが存在する意義は微妙なところ。というわけで、「経験上アート出身の人たちがここまでやることは少ないのかな」という部分をいくつか拾ってみる。今回はそこまでやってないけど、このあたりのテスト実装をするのにも、ファイルエクスプローラはほどよく機能する良いネタだと思う。
高速化と非同期化
できるだけさくさく動くツールを目指しましょうという話。実際のところこれがなかなか難しいんだけど、だからこそエンジニアが実現する価値のある部分でもある。
表示を状況に追従させる
たとえば、とあるファイルを右クリックしたときに「○○で開く」というメニューを表示させるとして、大人の事情で編集されたくないファイルというのも間々ある。そういうときに、「編集の可否」を内部コンテキストとして保持しておくと、編集付加なファイルに対しては「○○で開く」というメニューをグレーアウトさせることができる。で、意外なことにその程度の機能補助でもユーザには「このファイルは編集できないのか」というのがちゃんと伝わる。もちろんユーザが「○○を開く」をクリックしたあとに「このファイルを開くことはできません」というダイアログを出してあげてもいいんだけど、そういうのはツールの挙動としてかっこ悪いし、そもそも開くことのないファイルに対して開くための操作をさせてしまった時点で、それはもう設計ミスと言わざるをえない。
Python 以外を使う
ごく個人的な経験からいえば、GIL を回避する手段が非常に強く制限される Python は、非同期処理を使い倒す今時の GUI プログラミングとは相性が悪い。たた、Maya をはじめとする DCC ツールを操作するときの生産性が高いので、DCC との連携手段としてはとても重要。もしその部分を切り離して考えるのであれば、最近なら C# あたりもがっつり使い込むのが早い。マルチプラットフォーム対応が必要なら Xamarin でいいと思う。WPF と Cocoa を両方覚える必要はあるし嵌りどころも多いけど、GUI の豪華さをほどほどに抑えられるケースでは、ビューモデルとデリゲートでうまいことやれば全体の 5～6 割くらいは Windows と Mac でコードを共通化できると思う。
非プログラマブルな拡張
TA を名乗る以上基本的な DCC スキル（＝データ生産能力≠絵心）は身に付けておいてしかるべきではあるのだけど、とはいえアーティスト向けに用意する仕組みのすべての仕様を自分が切るべきかどうかはまた別の話。非エンジニアが理解できるフォーマットの設定ファイルに操作そのものをシリアライズすることができれば、少なくともその範囲内では、アーティストが仕組みの挙動をカスタマイズできる。というか、そういうのを全部自分でやっちゃうと工数がいくらあっても足りない。アーティストに対して何を外注できるかを考えるのは、エンジニア TA にとってとても意義のあることだと思う。主に自分の業務をブラック化から守るために。
例えば「データをどう表示するか」の部分なんかはその典型例。基本設計段階での UI スケッチなんかも、主たるユーザであるところのアーティストにお願いしたほうがむしろお互い幸せになれる。一番の基礎になる機能さえこちらから提案すれば、そこに載せる上っ面を綺麗に考えることのできるアーティストはちゃんと探せばちゃんといる。エンジニア TA としてのオリジナリティはその上に被せていけばいい。
プログラマブルな拡張
エンジニアとして TA 業務を進めると必ず出てくるのが引き継ぎの問題。自分のコードを拡張してくれる相手がとにかく少ない。というか基本的にそういう相手はいないと考えたほうがいい。そういうときに、「ツール本体はちょっとしんどいけどスクリプトぐらいならやってもいいよ」と言ってくれる相手がいると、それだけですごく楽になる。もちろんそういう人不足をどう扱っていくかという組織的な問題はあるんだけど、それはまた別の話。
あと、実装のコストパフォーマンスを目指していくと、自然と発想は「異なる複数のユースケースに対応する」ことに向かっていくものだと思う。とはいえさすがにそのレベルでユーザが変わっちゃうと要求仕様のレイヤから変わってることも多い。そういうときに仕組みの挙動を丸ごと入れ替えられると強い。「プラグイン化」というと一気にハードルが上がるけど、例えば Unity の AssetPostprocessor みたいに、適当なスクリプトを処理の前後に挟み込むだけでもだいぶ違う。ただし、何も考えず Python のプロセスを叩いてスクリプトを丸投げするようなことはやめておこう。まず仕組みとして汚いし、新規でプロセスを起動するコストも馬鹿にならない。何よりツールとスクリプトとの間でデータをやりとりするのがものすごく面倒だ。たとえば C# なら CodeDOM や PythonNet があるし、PySide ならそのまま eval してあげるほうがずっといい。
こういうのを実装するのに必要なのは絵心でも技術力でもなく、エンジニアとしての業務理解能力のはずで、エンジニア TA としての特性をまさに発揮する場面のひとつだと思う。「KISS 原則を守る」ということは「拡張性を捨てる」という意味ではない。
