とりあえず，開発者だけに表示されるテーマ切り替えボタンを追加し，見触れを整えた（テーマ切り替えボタンの様子）。
歯車アイコンの流用でどれだけ分かりやすく出来るか不安だったため，前回案では「トグルボタン風」ということにして，「明」「暗」の字を添えることを考えていたが，思いのほかすっきりしたトグルボタンにまとめられた。
歯車アイコンは hue-rotate() や brightness() で調整，月アイコンも CSS のみで実装，transition だけで簡単にそれらしい動き付けも出来，低コストで十分な見触れの切り替えボタンが出来た。
実装は中途半端だが，仕様は固まっているのでほとんど出来たも同然だ。
自動ページ展開機能実装が一段落した。細部に課題はあるが，実用出来る水準に達した。出振るい・手定め済み。
これに伴い，正式離立前に試していた全知検索窓や新規描出フォームの固定表示を復活させる検討も大きく進んだ。また，輪郭一覧の動的追加の仕組みを整えたことで，検索や新規描出時にも応用出来るようになった。輪郭一覧の更新が効率的に行えるようになり，高速化にも大きく貢献するだろう。
AutoPagerize 対応をどうするかというのが難しい問題だったが，これは挿入を監視して削除，注意書きを表示する方向に落ち着いた。最初以外 .autopagerize_page_element に display: none を設定しておくことで表示には影響しない。
AutoPagerize は，ウェブ利用者全体ではわずかな利用率だが，デライト用者が使っているのを見て私自身が使うようになったというのもあり，用者層の重なりは小さくない。出来るだけ混乱させないようにしたかった。
今後，広告の調整が重要になってくるため，ここで運営者・開発者向けにダミー広告を表示する仕組みを整えた（ダミー広告の様子）。
AdSense は，設置者によるクリックはもちろん無闇に表示させることも避けるべきとされているので，これまでは単に非表示にしていた。
機能的に自動ページ展開機能と似たところがある描写後略機能の実装方針検討もほぼ完了。
内容の高さが高さ制限に足りない場合どうするかが最後の課題だったが，これは舞覧側で追加取得すればいいことに気付いて解決した。
デライトには「使い方」というページがあるのだが，これは最初の頃からまともに更新出来ていない。デライト開発もありがたいことに快調で，いちいち更新していられないほど変化が激しかった。このあたりも近日中に刷新するので，もうしばらくお待ち頂きたい。
もっとも，多くのデライト初心者が躓いているのは，細かい操作方法というより，どういう考え方で使っていくものなのか，という所なのではないかと思う。デライトで躓きやすい「使い方の考え方」について，このあたりで少し補足しておきたい。
デライトは風変わりで慣れが必要なものではあるが，特に難解なものではない。開発者の力不足による不親切さは多々あるものの，あくまで誰でも使えるものを目指している。まずは，ちょっとしたゲームのルールを覚えるつもりで読んでもらいたい。
デライトは，個人の知識をよりよく育て，生活の様々な場面で役立ててもらうためのサービスだ。それを突き詰めた結果として，互いに入れ子に出来る「輪郭」という単位で情報を扱う仕組みを持っている。
ここでいう「輪郭」というのも，まずはごく普通の言語感覚で理解してもらえればいい。ある物事の全体を取り囲むもの，という意味だ。もっと具体的にイメージしたければ，手で輪っかを作り，目に見える風景の一部分を切り取って見てほしい。写真の構図を考える時などに似たことをよくやるが，その時に手で作っている輪っかは，世界のある部分の輪郭だ。
その輪郭を，自由に“保存”出来たらどうだろうか。輪郭の中にまた輪郭を作ることも出来る。一つの輪郭は，他の無数の輪郭を含むものであると同時に，他の無数の輪郭に含まれるものになる。そのようにして，“世界を捉える”ことは出来ないだろうか。さらに，この考え方をコンピューティングに応用することで，従来の情報管理が抱えていた問題を解決出来るのではないか。ここからデライトの輪郭という仕組みが生まれた。
例えば，ファイルをフォルダ（ディレクトリ）という入れ物で分類管理する仕組みは広く使われているものの，人間が頭の中で扱っているようには情報を扱えない。一つの物事をどこに分類するかは，見方によっていかようにも変わりうるからだ。これは，一つの情報を一つの入れ物に所属させるような「階層構造」一般の問題（こうもり問題）としてよく知られている。
他方，こうした問題を解決するため，より柔軟な「ネットワーク構造」（グラフ構造とも）を利用した仕組みも広く使われている。Wikipedia などで利用されているウィキはその代表例だ。ウィキは，ウェブのハイパーリンクという仕組みを最大限に活かし，縦横無尽にリンクを張り巡らしながら情報を整理出来るように設計されている。しかし，こうした技術も万能ではない。柔軟な分，散漫・乱雑になりがちで，焦点を絞って情報をまとめることには向いていない。
昨年11月30日から Galaxy S21 5G で写真を撮り始め，写真上信の環境を整えたが，これをきっかけに第二次知番改良，第二次快調期とデライト開発が急進展したため，11月30日の最初の4枚しか上信出来ていなかった。写真よりも開発記録のための画面撮りの上信に活用することが多かった。
最近，良い春の写真が溜まってきたこともあり，なんとかしたいと思っていた。大輪郭整備といいつつ輪郭整備もろくに出来ていなかったので，輪郭整備を兼ねた写真整理という形が良さそうだと考えたものの，間もなく第四次宣伝攻勢という時期で開発時間を削っていいものか，迷いがあった。
この日はサイクリングという天気でもなく，姉が姪達を連れてくるので開発に集中出来そうでもなく，とたまたま輪郭整備兼写真整理に適した条件が揃った。想像していたよりずっと手応えが良く，デライトが豊かに感じられる。やってみて，むしろこれは第四次宣伝攻勢前にやっておくべきことだと気付いた。新生デライトが「仏作って魂入れず」になるところだった。
一日がかりでやれば S21 で撮った写真くらいは終わるかと思ったが，思いのほか量が多いので，開発作業の合間に少しずつやっていくことにした。過去の写真が片付いたら新しい写真をこまめに上信するようにし，デライトにおける日常の表現をより豊かにしたい。また一つ，停滞していた課題が良い方向に滑り出して清々しい気分だった。
日本では S22 の発売日が今月21日になったが，一時考えたように待っていたらこの快調期は別の形になっていたかもしれず，良い春の写真も撮り逃していただろう。そう考えると，あの機種変更も奇跡的な出来事に思えてくる。
SLFS の起動管理系を整えたことで，そろそろ画面管理系も欲しくなってきた。規模的に早期独自実装も視野に入る。
知機における自我認証に PAM の採用を検討。画面管理系について考えていたところで気付いた。
現状の輪郭選り手の問題として，文章においても部分編集がしにくいという問題があり，用者からも指摘されている。
予てから問題だとは思いつつ，その感覚的な問題らしさに反して，かなりの長文も書いてきた私があまり困ったことがないのが不思議だった。よく考えてみると，長文であればあるほど誤字脱字や気になる箇所が増えるし，まず修正箇所が一点に収まることがないので，結局，最初からざっと点検しつつあちこち修正する，という作業をしていることが多い。こういう修正の仕方だと，最初から全体を選り手で開いてしまった方が無駄な表示の切り替えなどがなく，かえって効率的とも言える。
とはいえ，こればかりは書き手の癖によるところが大きく，手段が多いに越したことはないので，部品単位編集の一種として段落毎の編集を可能にするなどで対応することになるだろう。
VirtualBox Manager}{VirtualBox Machine}{弄ってみた}{相性の問題}(47)VirtualBox の設定調整などで終了。
これから仮想機の使用頻度が上がりそうなので，VirtualBox を最新版（6.1.30）に更新，少し設定を整えた。
動作は多少軽快になった気がするが，元々あったリサイズ周りの癖がひどくなった。dwm との相性の問題かと思い config.h を弄ってみたが，フローティング対象に WM_CLASS の VirtualBox Manager は効くのに肝心の VirtualBox Machine が効かない。
環境設定 → ディスプレイ のヒントで指定しても駄目，VBoxManage で設定しても駄目だった。慣れでなんとかなる問題ではあるのでしばらく様子見。
2回目の新型コロナワクチン接種を済ませた。これでコロナに関してもやるべきことはやり，あとはこのまま収束してくれるのを待つばかりだ。
体調はすこぶる良く，気分も落ち着いている。金風からの一ヶ月で限りなく理想に近い環境も整えた。明日からは新生デライト開発をしっかり再開出来そうだ。