ドラッグ&ドロップのついでに、画像ファイルを桃にドロップした場合レイヤーとして読み込むようにした。また、Alt+[、Alt+] でアクティブなレイヤーを前後に切り替えられるようにした（Photoshopと同じ）。
その他、Ctrl+Shift+[、Ctrl+Shift+] などアクティブなレイヤー自体を前後に動かす系のショートカットも実装したのだがこれがとても難しい。
処理自体が難しいのではなく、ショートカットの扱いが難しい。キー入力は keydown イベントで受け、KeyboardEvent#key で判断することになる。一方、Shift を押しているか否かでマッピングが変わる系のキーというものがある。こういったキーを keydown イベントで取得すると例えば Shift+[ というストロークは Shift+{ という扱いになる。これが正しいのか間違っているのかよく分からない。入力された文字と押されたキーの混同が起こっている。はて。
大量にレイヤーを追加した場合、当然ながらレイヤーパレットの最大表示幅を超えるレイヤーサムネイルが生成されることになり、隠れているサムネイルの表示の制御はユーザーのスクロール操作によって行われる。
さて、レイヤーを並べ替えるためにドラッグを開始して、スクロール領域から隠れている場所にドロップしたい場合、スクロール領域の端っこにポインタを持っていくと自動的にスクロールするような機能が必要になるのでそれを作らないといけない。
ところが驚くことに。そういう機能作らないとだなーめんどくさいなーなどと思いながらドロップを試してみた所、すでにそういう動作をするではありませんか。んん〜？ ブラウザの標準の機能なの？
Chromium ではだいたい想定したとおりの動作をし、Firefox ではスクロール領域の端っこでポインタをちょこちょこ動かした時に限り自動スクロールするようだ。ふーんじゃあ別にコードを書かなくてもいいのかな。
だいたい、というのはスクロール領域内部の端っこだけではなく領域の外側も自動スクロールのトリガーになっててほしいのだけど、まあ、いいかな。
さてレイヤーパレットができたことでヘッダ部分のレイヤー周りは不要になったので、色々と整理した。また、描画ツールのオプションはポップアップ形式をやめ、ヘッダの下部に表示するようにした。
レイヤーパレットの実装がもうちょっと続く。ドラッグ&ドロップによるレイヤーの並べ替えが必要。
割とどうでもいいことなのだけど一応メモ。
X Window System が持っているセレクションはたとえば xclip といったプログラムでアクセスできる。
このとき、例えばテキスト以外、例えば画像とかをやり取りするにはどうするんでしたっけ？ そのような場合は target オプションに ATOM を指定する。ATOM ってなんだろう…。
ATOM はここで定義されている: https://tronche.com/gui/x/icccm/sec-2.html
X11 の用語自体に ATOM というものがあったようが気がしないでもないが、関係があるのかはよく分からない。さてこれを参考にした上で、画像はどれになるのかと言うと実はどれでもなく、mime タイプを指定する。
$ cat foo.png | xclip -i -selection clipboard -target image/png
ここで jpeg とかをコピーしてもアプリケーションによっては対応してないこともあるので、必要ならコピー前に png に変換するなどの処理が必要。
とここまで書いて思ったのですが X11 から Wayland へみたいなドラスティックな変更を行った場合この辺どうなるんだろう。ググってみると当然ながら Wayland が面倒を見ることになるようだ: https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-data-sharing
この辺を考えるとディスプレイサーバという名称がふさわしいのかどうかよく分からなくなってくるが、気にしないことにしたい。
ということでクリップボードからのペーストができるようになった。
貼り付ける画像のサイズは無制限でいいんだろうか？ 制限をかけるとすると、閾値を越えたときはエラーにする？ 適当にリサイズして貼り付ける？ どちらも良くない感じがする。制限はかけず、32768×32768ピクセルの画像をペーストしてブラウザがぶっ飛んでもまあそういう日もあるかもね的精神でいきたい。
ちなみにレイヤーの枚数には制限があり、とりあえず100枚を限度にしている。
ところで navigator.clipboard.read() で画像を読み込む場合、それで得たクリップボードアイテムをblobに変換し、そこからオブジェクトURLを生成し、img要素に読み込ませ、それをcanvasに描画という手順が一般的なのだが、最近はImageBitmapというものがあるそうなのでそれを使った。javascriptの世界は日に日に新しい機能が追加されて困っちゃう。ImageBitmapはblobから生成できて、そのままcanvasへの描画ソースになれる。
ぼちぼちレイヤーパレットの機能を埋めていく。
Xubuntuでaptによるアップデートを何回か繰り返すと、そのうちにデスクトップに謎のマウントアイコンが出てきて、これの正体がよく分からない。なんだろうこれ。
レイヤーとレイヤーの隙間に意味を持たせて hover 時に追加ボタンを出すようにした。
だいたいこんな感じでいいかな。
レイヤーパレット上のツールバー的なものをどこに配置したものだろうか。
もっとも、ツールバーと言っても、とりあえず実装するのはカレントレイヤーの削除と新規レイヤーの追加くらいである。前者は対象がカレントレイヤーであるのだから、そのためのボタンをパレット上のカレントレイヤー領域のどこかに配置するのが当然、自然だろう。
一方で後者が難しい。新規レイヤーが常に最前面への追加なら、カレントレイヤーは関係ないのでツールバー的な領域を新設してそこへボタンを置けばいいが、カレントレイヤーの手前に追加と言った動作ならこれもパレット内のカレントレイヤー領域内に置くのが多少は自然に思える。
多少はというのは、確かに動作の起点はカレントレイヤーなのだが、動作の対象は別の新規レイヤーなのでそこに若干のズレを感じないこともないということだ。
難しい。どうしたものか。
レイヤーパレットというものに正式な定義があるわけではないが、大体のイメージはPhotoshop 3.0から実装されたアレである。
これを整理してみるとこの中に存在するオブジェクトは
とこんな感じになる。面白いのは合成モード云々が上にまとめられていることだ。これらは当然各レイヤーの属性なので、本来はレイヤーリスト中の各レイヤー項目内に配置されて然るべきものなのだが、おそらくパレットの面積の都合で上にまとめられている。
これに対して、レイヤーの可視状態とリンク状態はまとめられてない。この切り分けにどういう理由があるのかは分からない。可視・不可視の状態は全体を俯瞰できた方がよいということか。
そんなこんなを勘案しつつ、桃のレイヤーパレットはこんな感じにしてみたい。
上部にはチェックボックスひとつしか置いてないが、ここには可視・不可視の状態や透明部分の保護といった各種フラグ群を表示する。また、合成モードと不透明度のためのUIは画像の通りの場所に配置する。
画像の通りといえば見ての通り、各レイヤーを横に配置している。これはちょっとチャレンジングで、これが使いやすいかどうかは実際にドッグフーディングしてみないと分からない。もしかしたら何だこのクソUIは！！となるかもしれない。