[クロス本草稿] アプリケーション・アイコン

クロス本 注意書き


本文章は、技術書典5にて[project daisy bell]( https://twitter.com/MNukazawa )がリリースする予定の、クロスプラットホーム・デスクトップアプリケーション・GUIフレームワーク・クロスレビュー本（仮）（以下、クロス本）の一部の草稿です。
校正前の文章・記憶により記述し未確認の内容・雑なmarkdown風紀法・張ってないURLリンク、などがあります。

# アイコン

アプリケーション・アイコンはデスクトップアプリケーションの顔である。
デスクトップアプリケーション固有のデザインテクニック（主に低解像度対応）があった。
モバイルアプリケーションに技術が引き継がれたかはわからない。
アプリケーション・アイコンはプラットフォームOSにより扱いが異なる。
クロスプラットホーム・アプリケーション・フレームワークは、それを吸収したりしていなかったりする。
というかGtk/Qtはともかく、electronだけはわりと吸収しようとしている。

## アイコンデザイン

アイコンの意匠をデザインする際、サイズ毎に固有のデザインをすることが推奨されている。
ドット絵のテクニックとして有名かもしれない。コーポレートデザインでも用途に合わせて微妙にバリエーション違いを用意するという似た技法がある。
ドット数が大きいアイコンではグラデーションなどを用いて意匠を凝らした美麗イラストを使う。
ドット数の少ないものほど要素を省き影や斜め線の少ないデザインにする。
[Microsoftの Windowsデスクトップ アプリケーション アイコンデザインのガイドライン]( https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa511280.aspx )

MacOSが1024x1024pxの巨大アプリケーションアイコンを使用することが一時期有名だった。
現在では、Windows7-10デスクトップでも大きなアイコンが使用される。
Webページのために16x16pxのfaviconアイコンを用意する時代もあったが、モバイルブラウザでは表示されないため事実上不要となった。
2018年の現代において、小サイズアイコンを専用で用意する意味はほぼ無い。

daisy_bellでは、省力化のために、アイコンはサイズフリーなベクタ画像で１種類のみ作成している。
サイズフリーといってもターゲットサイズが無ければデザインの複雑さレベルの方針が立たないので、WindowsとMacOSXの間を取って、512x512pxサイズを基準にしている。

<<ここにlina_dictoのアイコン>>

lina_dictoでは、辞書アプリケーションでは典型的な開いた本の形をベースに、エスペラント語のテーマカラーから塗りを緑色、エスペラント語のシンボルである緑の星を反転した抜きとして使用した。
緑の星に、たぬきの尻尾が生えているのはもちろんすべての元凶たる「ことのはアムリラート」を意識しているため。
ところで、念の為調べてみたところたぬきの尻尾に縞模様があるとは限らないらしいのだが、まあ深く考えることなく縞模様にした。アライグマになってしまったかもしれない。
リリース時はよく出来たアイコンデザインだと自画自賛していたのだが、後にlina_dicto for englishのアイコンをデザインした際に、lina_dictoのアイコンは複雑過ぎたなと思い直して反省している。
サイズフリーデザインにするための工夫として、緑の星などの意匠は小サイズでは印象から消えて、ぱっと見では「緑色の辞書アイコン」に見えるように、サイズを調整している。

<<ここにlina_dicto for englishのアイコン>>
英語版はあくまでlina_dictoのオマケなので、アイコンデザインも検討の時間すら略する勢いで描いた。
青色は個人的な英語のテーマカラーであるため。端を丸めた線で開いた本の形を示して辞書アプリケーションのアイコンとした。
結果的に、「辞書アプリケーション＝本の形」というステレオタイプは強力であったために、本家よりもシンプルさで見れば出来が良いアイコンデザインとなってしまった。
不本意な気持ちを感じなくもない。

<<ここにdaisy sequenceのアイコン>>
業務用を意図しているので黒色単色アイコンで大人っぽく（言い方が子供っぽい）。
シーケンス図のlifelineをテーマにしようと決めて、将来的なPlantUML対応を見据えていたのもあって植物っぽい意匠を取り入れようというところまでは考えたのだけれど、具体的にデザインに落とし込むのが大変だった。
一度は捨てようかと思った。
基本のデザインが決まってからも、重なり部分の抜きとか微妙に調整する必要があり、全体的に難産だった。

## アイコンデータの作成

Windows/MacOSXの場合、複数サイズの画像を1ファイルにまとめたアイコンファイルを用意する必要がある。

Windowsではicoファイルを使用する。
icoファイルはGimpで作成できる。
機械的にサイズ違いのレイヤを作ってicoファイル形式でエクスポートするだけなので、自動生成させたいところだったが、Gimpの自動化は自分にはハードルが高かったため手作業で行っている。
GimpにはPython/Schemeによるスクリプト機能はあるのだが、コマンドラインから叩けるかは不明。

Linuxにはアイコンフォーマットがそもそも存在しないので、画像サイズは1種のみで、普通のPNGとかjpgとかを使う。

MacOSXではiconファイルを使用する。
iconファイルはGimpでは作成できない。プロプライエタリなファイルフォーマットなのか、作成するにはMacOSXが必要である。
フリーな実装として<<実装名>>というコマンドラインツールがあるが、私の環境と用途では正しくアイコンファイルが作成されなかった。
(具体的にどううまく行かなかったのかは覚えていない。)
画像ファイルからiconファイルを作成するWebサービスがある。これは機能する。
[ Convert PNG to ICO and ICNS icons online - iConvert Icons ]( https://iconverticons.com/online/ )
以前一度、数日サービスが止まっていたことがあり、管理者へメールを書いたことがある。後日復活した。
このサービスで作成したアイコンは、Ubuntu18.04付近のNautilusファイルビューアのサムネイルでは砂嵐になり、正しく表示されない。だが正しく機能する。
コマンドラインツールで作成した方は、サムネイルでは正しく表示されていたように思う(が、記憶が定かでない)。

### Windows
Windowsにおいて実行ファイルにリソース情報として作者名などを付与することができる。
実行ファイルのアイコンは、リソースの一種である。
MinGWにWindowsターゲットのリソースエディタがあり、Linux上からでもWindows実行ファイルのリソースを操作できる。
（実行ファイル名: `x86_64-w64-mingw32-windres` あたり。）
それを使って実行ファイルにアイコンをリソースとして連結しているものと思われる。

### Linux
Linux実行形式のELFには、Windowsのようにディストリビューション汎用に使えるアイコンリソースの仕様はない模様。
debやrpmは、アイコンを独立した画像ファイルとして持っている。
インストーラによりインストールする際に、環境によりGnomeやKDEのアプリケーション・ランチャに登録するものと思われる。
インストーラがない場合は、ランチャからはアイコンのないアプリケーションとして扱われる。
(Unityデスクトップではデフォルトのアプリケーションアイコンに、デフォルトのアプリケーションアイコンが使用される。警告のような斜め線の入ったアイコンが使用される)
<<ここにUnityデフォルトのアイコン画像のスクショ>>
Ubuntu18.04でlina_dictoを動かした際に、前のバージョンのUbuntuでは問題なかったアプリケーションアイコンが突然認識されなくなり、デフォルトのアプリケーションアイコンになってしまった。
electronのインストーラ作成パッケージ<<の名前>>のバグに近い何かだろうと思ってissueを立てたところ、後日、アプリケーション側で起動時にアイコン画像を指定することが必要になったことが原因だという返答をもらった。
[electron-installer-debian
/application icon broken in ubuntu 18.04 alpha dash area #135]( https://github.com/unindented/electron-installer-debian/issues/135 )
アイコン画像のフォーマットは普通のPNGを使っている。icoファイルなどが使えるのかは必要なかったため確認していない。

### MacOSX
electronのdeployシステムによるMacOSXバイナリへのアイコン付与が、Linux上でも実行できていることから、MacOSXも実行ファイルのどこかにアイコン画像のデータを埋め込むとそれをOSが読んで表示してくれるものらしい。
(他に書くこととくになさそうなので以上)

## アイコンデータの実行ファイルとの結合

### electron
electronではdeplyシステムがWindows/MacOSXの実行ファイルにアイコンの結合を行う。
[パッケージzip作成 electron-packager]( https://github.com/electron-userland/electron-packager )
前述の通り、Linuxのみdeployとは別に、アプリケーション起動時に画像ファイルの指定が必要となる。
[deb作成 electron-installer-debian]( https://github.com/unindented/electron-installer-debian )

[Linux向けのアプリケーションアイコン登録コード例]( https://github.com/MichinariNukazawa/lina_dicto/blob/master/lina_dicto/index.js )
```js
 13 >-------// Create the browser window.¬
 14 >-------win = new BrowserWindow({¬
 15 >------->-------width: 800,¬
 16 >------->-------height: 600,¬
 17 >------->-------icon: 'image/icon.png'¬
 18 >-------})¬
```

### Gtk
アイコンリソース共通化レイヤのような高度なものはない。
ビルドシステムと同じで、Gtk側で独自なものは用意していないので、WindowsではMinGWに頼るなど、プラットフォーム毎になんとかする。

### Qt
Windowsのrc形式リソースファイルを書いてqmakeビルド設定ファイルに登録しておくことで、ビルド時に勝手に結合される。
Qtはアプリケーションのアイコンを扱うつもりはないらしく、この方法も、どちらかというとWindowsリソース情報のオマケ扱いに思える。
Linux、MacOSXではリソースファイルは単に無視される(とドキュメントに書いてあった気がするし、Linuxでは実際そうだった)。

[qmakeファイルでのRCファイル登録マクロの記述例]( http://d.hatena.ne.jp/QtCoder/20110910/1315838284 )
```
win32:RC_FILE = icon_win32.rc
```
[qmake RC_FILE 参照URL]( http://doc.qt.io/archives/qt-5.5/qmake-variable-reference.html#rc-file )