Have to press twice

Chrome 上で vi っぽいキーバインディングを再現するよ系の拡張としてcVIMを入れている。のだが、最近になって不思議な動作をするようになった。

:とかaとかtを押すと1行入力のプロンプトを求める状態になるはずが、なぜか2回左記のキーを押さないとプロンプトが出なくなってしまったのだ。不思議なことに従来通り1回押せば出るページもある。またそのページでも状態によって出たり出なかったりする。ランダム。

cVimのコミットもすっかり頻度が低くなってる今日この頃だけど、直るんだろうか。

Love is heavy

Xubuntu 上の Chrome がいつの間にやらすごく CPU を使うようになっている。top -H で見てみると Chrome_IOThread なるスレッドが常時 50% ほど回っている。なんだこれは。何を I/O しているんだ。

というわけで仕方がないので Chromium を引っ張り出してきた。こちらは特に CPU 浪費とかはしない。というか、別に Chromium で十分なのだった。そもそも Xubuntu インストールして標準で入ってるブラウザだ。

それをわざわざ Chrome にスイッチしたのはきっと何か理由があったんだと思うが、思い出せない。YouTube の動画で見られないものがあるとかそんな理由だったかもしれない。

ところで久しぶりに Chromium を起動して設定を開いてみると、Google アカウントでログイン云々の機能が入っている。そのあたりは Chromium はフリーで Chrome に固有という切り分けじゃなかったのか? よく分からない。

All layers are independent in size

従来はすべてのレイヤーの大きさはキャンバスの大きさであり、また背景レイヤーの完全に直上にある構造だったがこれをやめ、レイヤーごとに大きさとオフセットを独立して持てるようにした。それに合わせて、いわゆるレイヤー移動ツールを実装した。

と文章で書くとこれだけなのだが描画のあらゆるところでオフセットを意識するように書き直すのは死ぬほど大変だった…。その割に見た目は何も変わっていないと言う。

次は矩形選択ツールを作る。

2 ways to install an application

言うまでもなく Ubuntu は Debian 系のディストリビューションなので、プログラムのパッケージをインストールするには apt を使い、deb パッケージを扱うのが通例だ。が、ここへ来て snap パッケージというものも使えるようになっている。

大きな違いとしては snap の方は対象がある程度の規模かつ OS からは独立したアプリケーションであるように思える。snap でインストールされるプログラムから見えるファイルシステムはサンドボックス化されていることからそれが伺える。

それから、snap の方は毎日アップデートがチェックされ、特にロックしない限り勝手に最新版に追従するとのことだ。へー。

ところで困るのが、deb と snap に両方同じアプリケーションがある場合と、あるタイミングでどちらかに移行した場合である。前者の場合は例えば gimp とか、vlc とかだ。両方入れるとどうなるんだろう? 多分大丈夫なんだろうけど、一応念のためにあらかじめ deb 側はアンインストールするようにしている。後者の場合は例えば Ubuntu 16.x 時は画像ビューアとして comix が用意されていたが、18.x にアップグレードするとそれが問答無用で削除され、特にアナウンスもない…みたいなことが起きる。これは snap 側に後継である mcomix が存在している。このように2つのリポジトリそれぞれの相関や移行と言ったその運用があんまり考えられていないように思える。

ファイルシステムのサンドボックス化と言えば、スクリーンショットを編集したい場合、従来だととりあえず PrintScreen キーを押して、出てくるダイアログで gimp での編集を選んで実行…という流れだったが。gimp を snap で入れるとホームディレクトリ以外の場所を触れない(正確には、触れるが本来のファイルシステムから分離される)のでその流れで編集できなくなった。スクリーンショットはとりあえず /tmp/ の下に保存されるからだ。

どうするかというと、いわゆる昔ながらの Unix 的な流儀から全く離れている気がするが、gimp 自身がスクリーンショット機能を持っているのでそれを使う。うーん。まあそれでもいいけどねーいやーそれはどうなんだろうねー。

特にまとめもなく突然終わる。

Telling you who I am

ここのサーバは xrea である。xrea のサーバには、ssh でログインできる。それを利用して、ローカル上の成果物を rsync を通して xrea 上に配布することができる。楽。

ただし、どのホストからも ssh で入れるわけではない。事前にブラウザからコントロールパネルページを開き、ホストを登録する必要がある。

さてこのコントロールパネルページが最近リニューアルされてなんかおしゃれな感じになったのだが、ところが新しい方には前述のホスト登録機能がどこにも見つからないのである。以前あちこち探しまくって、こんなところにあったのか! となったことは数回あったのでどこかにはあるんだと思うが、現在は全然見つからない。

そんなわけで、古い方のコントロールパネルに切り替えた上でホスト登録をするという作業を強いられて、実に面倒くさい。

ところでリニューアルに伴って、コントロールパネルの機能をプログラマティックに呼び出す REST API が設けられたという。この中にホスト登録機能も含まれているので、ローカルの cron でよしなにすることにした。

それにしてもホスト登録機能、どこ行っちゃったんだろ…。

Curse of cursor

キャンバスに描かれるペンのサイズを事前に図示するために、カーソルの形状を CSS の cursor プロパティにより変更している。

が、Chrome ではこのプロパティにより設定できるカスタムカーソルの最大サイズに制限がかけられることになると言う。

https://www.chromestatus.com/feature/5825971391299584
https://bugs.chromium.org/p/chromium/issues/detail?id=880863

カーソルの形状の変更はおそらくネイティブなウィンドウシステムの機能に依存しているだろうから、最小公倍数的な仕様に揃えるということなのかな? と思ったらどうもカーソルの形状を変えることで誤クリックを誘導するような邪悪な広告対策のようだ。なんて世知辛い世の中だ。

というわけで桃缶でもそういう対応を入れることになったのであった。

Layer the drawings

ふたばの一部の画像掲示板には手書き機能が備えられている。が、赤福プラスはふたばのページを自前のページ構成で上書きしてしまうので、その備え付けの手書き機能をそのままでは利用できない。そこでだいたい同等の手書き機能を赤福プラス自身が内包している。

しかしこの手書き機能が別に使いやすくもなんともなかったりする。とはいえ手書き機能は長年 dat にも img にも関係なかったのでつまり別に困ってなかったのだが、今回 img でも手書き機能が有効化されたので、そういうわけにも行かなくなったのである。そこで改めて手書き機能を眺めてみると、いろいろと機能が欲しくなってきた。具体的にはレイヤー機能が欲しい。

とそういうことで作ってみた。とりあえず開発しやすさを鑑み、赤福プラスとは独立したブックマークレットとして仕立てた。そのほうが多くの「」やとっしーも試せるし。

桃の缶詰
https://appsweets.net/momo/

ネーミングは例によって別に意味はない。さて公開後のいろいろな不満を浚ってみると、だいたい以下の2点に集約されるようである:

  • 機能が多すぎるからクソ: つまり、手書きのミニマリズムに反しているのではないか? という指摘だ。しかしこれはその機能を使わなければいいだけなので、批判としては弱い。
  • ペンの補間がクソ: こちらは聞くに値する。手書きの拡張スクリプトとしては肌色キャンバスというものがすでにある。これも描線の補間をするのだがよくできていて描き心地が良い。それ比べると桃缶はクソだな! という評価なのである。

Async moderation

書き込みに del を入れる際、いつの間にかリクエストに間を置かないといけなくなっている。そのインターバル内に複数リクエストすると「操作が早すぎます」云々と怒られる。

現状では del フォームの OK ボタンが押された際に同期的に処理していたのだが、これを改めて del リクエスト専用のグローバルなプロミスを用意し、OK ボタンのハンドラでは単にそのプロミスにリクエスト(及び 10 秒待機するディレイ)をチェインするだけにした。これにより操作が早すぎると怒られることはなくなる。また、del 済の書き込み上の del リンクはイタリック体にするようにした。ただしこれは永続化的な処理はしてないのでページをリロードすると元に戻る。

副作用として、山ほど del を入れて即ページを閉じたりすると予約されたほとんどのリクエストが水の泡となってしまう。まあ普通山ほど del を入れること自体がかなり奇妙な行動なのでこれはこれでいいか。

Tegaki has returned to img

虹裏 (img) でレスに手書き画像を添付できるようになった。以前は逆に、手書き画像でスレッドを立てられる仕様になったことがある。しかしこれにより管理人さん曰く「板が破綻した」結果となって、撤回された…という経緯がある。しかし今回は、今のところ上手く回っているように見える。

そういうわけで、諸々に対応した。最も重要なのは、レス送信モードで手書きが有効な場合に画像の貼り付けに対応したことだ。これの何が面白いのかと言うと2点あり、

  • 手書き画像の持ち越しができる: 虹裏 img のスレッド保持期間は非常に短い。絵を書いてる内にスレッドが落ちてしまっていたということも頻繁に起こりうる。そこで、キャンバス上のコンテキストメニューで画像をコピーし、別のスレッドで貼り付け、そのまま手書きモードに入れば続きを描くことができるようにした。
  • 擬似的な画像レスができる: これは上記の仕様の副作用だ。つまり手書きキャンバスにクリップボード上の画像のみならず、ローカルな画像ファイルの内容を流し込むこともできるようになっている。擬似的なというのはこの手法の場合画像の横幅、縦幅はかなり制限されたものになるし(おそらく最大400pxほど)、フォーマットは png に限定されるのでそれ以外は使えないということだ。それを踏まえても、一応画像レス的なものはできる。ちなみに、つらつらと img を覗いてみたところたまにこの手法ではない本来の画像レスをしていた例もあったので、何か別のハックがあるのかもしれないが、それはわからない。

テストのために適当に手書きをしてみたものの、trackpoint で絵を描くのはとてつもなくストレスフルだ。何か適当なペンタブレットを探してみるかな。

Narrow world

ウィンドウを狭くした際に盛大に崩れるのでそれなりになるようにした。

そう言えば Chrome って横幅のリサイズに限度ができてたんだっけ。この最小の横幅って全てのプラットフォームで共通なのかしら。