(あいまい)
設定ページ整備,エクスポート機能実装からの改行交度正規化についての検討・修正作業で終了。
KNEST では,入力を適宜正規化することにより,原則として改行交度を LF として扱うことにした。これまで曖昧だったため,出場の dln
にも LF と CRLF が混在しており,Dex での処理前にいちいち正規化していた。出場の CRLF は置換し,描出時に正規化することにした。
libxtd の HTTP ライブラリの仕様にすることも考えたが,低層でいちいち厳密な検査などをしていると必要性に対して高コストになる。必要な場面は限られているため,KNEST で扱うべきと判断した。改行交度正規化用の Dex::nmlz_v()
は KNEST::nmlz_v()
に移動した。微妙に使いにくい位置にあり適当に写し貼りして使っていたのですっきりした。
改行交度の仕様を決めておく必要があるエクスポート機能実装がきっかけとなったが,これで将来的な混乱も防げ,多少無駄な処理も削れた。
領下手定め環境では置換・交度修正・手定め済みだが,急がないため未出振るい。
エクスポート機能では LF で決め打ちにするつもりだったが,仕様の見通しも良くなったので CRLF を選択出来るようにすることにした。
Windows 向けの CRLF と Windows 以外向けの LF として,用影で簡単に初期値を切り替えておけば十分だろう。
なぜ混在していたのかと思ったら,フォーム送信では CRLF,XMLHttpRequest
では LF というややこしい仕様の違いがあったらしい。前縁ではある時期から XMLHttpRequest
を主に使うようになっているため,実装の変化によるものだろう。
設定ページの全体的な領当てがついに固まったのでまとめて終了。開発者通類で領当て案を作った。
特に悩ましかったのがタブ設計だったが,これは概ね以下のようにまとまった。
最後まで悩んでいたのは,現状で名前設定・アイコン設定を置いている部分のタブ名だった。
「見え方」では用合いの外観と紛らわしい。必ずしも他者を意識したものではないので「自己紹介」も微妙に違う。「表現」も曖昧だ。「基本」で誤魔化すことも考えたが気持ち悪さが残った。
今日,ここは素直に「プロフィール」にしておくかと考えたものの,「プロフィール」「認証」「データ」「状態」という語の並びが美しくない。この並びは設定の自然な流れを重視したものだが,多少妥協して「プロフィール」「データ」「認証」「状態」としても偏った字面が気になる。
やはり在来語表現が必要だと思い直した時,「見せ方」という表現を思いついた。日本語としてしっくり来るし,簡潔だ。「見せ方」「認証」「データ」「状態」と並べても,適度に語種・文字数が分散していてばら成しが良い。
本当に長いこと,納得の行くタブ設計が出来ないことで領当てがまとまり切らなかったが,これが解決してようやく,すとんと落とし込めた。
設定画面・設定ページというのは会社のトイレみたいなもので,デザインや見触れは等閑にされやすいが本当の美意識が露呈するところでもある。性格的にどうしても妥協出来ない部分だったので,非常にすっきりした。
知名欄・描写欄の捕活に関する仕様検討の結果,ともに「マウスオーバーで捕活する」仕様を確定・実装した。出振るい・手定め済み。
仕様というほど明確なものではなく,時期によって実装上機能しないこともあったものの,デライト初期実装からのマウスオーバー時の挙動は,知名欄では捕活・全選択,描写欄では捕活,という方針だった。これは,実用上の都合というのも大きく,こうでなければ単純に描出効率が悪かった。
昨年9月までの第二次用合い改良中の交度整理で,知名欄の捕活・全選択は機能しなくなっていた。これは確か,中景輪符の事象を改良したことで干渉の懸念があり,再実装を後回しにしたという経緯だった気がする。もっと地味な描写欄の捕活は過去に何度か再実装した記憶があるものの,どの時点で機能しなくなっていたのかは曖昧だが,いずれにせよ,第二次用合い改良後はどちらもマウスオーバーでの捕活すら機能しなくなっていた。
もしかしたら,これはこれで今のデライトでは悪くないのかもしれないと少し様子を見ていたが,輪郭整備のように描出効率が重要な作業になると,クリックでの捕活はやはりまどろっこしく,鈍重に感じる。そこで最近はかつての挙動を復活させる機会を窺っていた。
懸念は,他要素・他機能との干渉や誤操作だったが,これは昨日の検討から急速に氷解した。今のデライトで,マウスオーバーで捕活が移動すること自体は前提のようなところがあるので用者体験に大きな悪影響はないだろうということ,むしろほとんどの要素がマウスオーバーに反応するのに知名欄・描写欄が無反応なことが直感性を損ねているとも言えること,スクロールとの干渉も実際の舞覧では生じないこと,誤編集の問題については,そもそも閲覧・編集用合いを切り分けていることが一定の保護機能になっており,更に取り消しボタンで変更有無が分かるようになることで大きく軽減されること,などの理由で,大きな問題はないという結論に達した。
そこでまず,知名欄の全選択も含めてマウスオーバーでの捕活機能を復活させてみた。ところが,知名欄の全選択については数十分で廃止を決定することになった。実装上の問題としては,選択状態がやはり周辺要素と干渉する。干渉しないようにマウスアウトで解除すると,今度は選択状態が意図せず解除されやすくなる。もっと問題なのは,誤入力で上書きしてしまいやすいということだった。全知検索窓では再検索のためにも上書きしやすい全選択状態が好都合だが,知名欄での利点は写し取りが素早く行えることくらいでさほど大きくない。
これは,今のデライトで,慣れ切ったこの挙動からいったん離れなければ気付かなかったことかもしれない。今のデライト市場戦略から考えても,熟練用者向け過ぎて採用出来ない。
次に,知名欄の全選択機能を外し,捕活だけにしてみると,これはむしろ想像以上に好感触だった。地味ながら,編集の軽快感は明らかに向上している。捕活さえしてくれれば Ctrl + A で写し取りも十分効率的に行える。今のデライトとの相性でいえば理想形とすら思えた。ここで正式な仕様として確定することにした。なお,捕活時に発生するスクロールは意図しない場合が多く考えられるため抑止する。
どこまで普遍的な現象か分からないが,常用している Linux の Firefox では,<textarea>
の選択状態を残して捕活解除すると,再選択のつもりが(未捕活状態のせいで)意図しない文字列ドラッグが発生しやすいため,これがなくなったのは個人的に嬉しかった。近頃多用している複数輪符の引き入れ欄への写し貼りで障害になっていた。
とにかく,第二次用合い改良後に残っていたもやもやしたものを払拭出来たのは大きかった。
<small>
}{置き換えられる}{補足部区}(73)4歩の案を以下のように修正した。強調度に応じて三段階となる(補足記法も同様)。
!--
小さな注意書き
--
!!--
通常の注意書き
--
!!!--
重要な注意書き
--
装体は,23日2歩の案を下敷きに,境界線・背景色無しで font-size: 0.8em
程度にした小書きのものを加える。この場合,一段階目の注意部区・補足部区は装体的に区別出来なくなるが,そもそも小さな注意書き・補足の違いは曖昧なものなので自然といえば自然だ。
そもそも,注意書きは目立つように書かれるものばかりではない,というところに引っかかっていた。
二段階か三段階かは迷ったが,二段階にして後から追加出来なくなるよりは,三段階にして一段階目が無用の長物になる後悔の方が小さい。
当初,記号の数で「重要度」を表すことにしていたが,内容の重要性と装体の目立たせ方は必ずしも一致しないので,「強調度」程度の意味合いにしておくべきかもしれない。
例えばデラング文書では,目次の項目の末尾に <small>----輪郭記法</small>
などと書いているが,これを ?----輪郭記法
に置き換えられるかもしれない。
23日12歩で書いた「小書き括弧記法を使わずに文字を小さくしたいと思うことはたまにあった」とはこのことだったが,あくまでも文字装飾記法の一種である文字サイズ記法やフォント記法で <small>
相当の表現を完全に代替は出来ない。
Dex_T
}{Dex::bl_T
}{部区}{Dex 改良}{Dex 行処理仕様}{希哲15年5月19日の開発}{特殊文字列}(64)途中で終了。
ここで Dex 実装(Dex_T)における行処理の仕様を確定させておくことにした。
次行への移行は Dex::bl_T 個体の Ctn() で自身を指す指示体を返すか,指示体を通して現在行変数に特殊文字列(現在は仮に"&&skip;"
)を設定した場合のみとし,それ以外は原則として現在行を維持する。
これまで,とにかく動くことを優先させて不明確な部分だったが,流石にそれで保守性を維持するのは難しい規模になっていた。
10日の開発でデラング不具合修正から Dex 設計見直し,記法実装へと移行してきたが,これも仕様の方向性を決めるためだった。一昨日の開発のリスト記法実装途中で,ある程度こうあって欲しいという仕様が見えてきて,昨日の開発で入ったのが「Dex 改良」だ。
これまでのデラングの不具合で多かったのが部区切り替えに失敗することだが,これも行処理の仕様が曖昧だったことが大きな原因としてある。
単純に入力を行毎に読み込み,それを部区個体のスタックで処理していくという実装だったため,「現在行が勝手に進んでしまう」という問題があった。これへの対応を部区実装毎にやろうとすると複雑化してしまう。
そこで,新しい部区や上位部区への移行時には現在行を維持し,同一部区での処理を継続する場合にのみ行を進めることにした。部区移行時にも明示的に次行に進める手段として,現在行を特殊文字列に置換する方法を使う。これは部分的に実装して好感触を得ていたため,部区毎ではなく共通処理化する。
bgn() と Ctn(),Ctn() と end() の間でも現在行を維持することにした。後者は従来通りだが,前者では次行に進んでしまっていたため,混乱することがあった。これは少し悩んだが,bgn() と Ctn() は共通処理が多くなるため,この仕様の方が単純化する場面が多いだろうと判断した。
要するに,特定条件でなければ現在行が動かないようにすることで挙動を把握しやすくする,というのが本仕様の意図だ。
本仕様で概ね問題ないと思われるが,しいて言えば,各部区個体の Ctn() 実装を厳密にしないと,容易に無限循環に陥いる。これまでのように行処理が勝手に進んで勝手に終わってくれないためだ。
ただ,無意味な循環を検知するような対策は難しくないので,大きな問題ではないだろう。