
{希哲16年5月26日8歩 K#F85E/A-E74C-62E1}
`Aejs_DG_rev`
}{長期的視野に立って}{更新方法}...
{希哲16年5月23日の開発 K#F85E/A-E74C-8D2F}
輪郭選り手抜控機能整備を概ね終え,ようやく出振るい出来た。追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。
この出振るいにより,中途半端な実装だった輪郭選り手抜控機能に一通りの機能が揃った。下書き抜控一覧も使えるようになり,抜控の把握が容易になった。予てから欲しかった新規描出フォームの消去・復元ボタンも抜控の削除のため追加した。18日の開発で実装した描写拡縮ボタンも使えるようになった。また,周辺の交度整理も大きく進み,理腑としての意義も大きかった。
利便性・信頼性の向上はもちろんのこと,昨年から中途半端な状態で引きずってきた当努が片付いたことによる精神衛生上の効果も大きい。昨年来の他の当努は本格的に着手していないか,着手して間もないので,ここから思考を整理しやすくなる。
抜控機能整備が長引いた最大の原因は,他にやりたいことが多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間に設計方針が変わったり深刻な不具合に気付いたりしたので,時間をかけたことで円滑に片付いた面もある。
再描出は知番でいいとして,新規描出の鍵をどうするか,というのは難しい問題の一つだった。昨年7月28日6歩から検索語を鍵に含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信の検索語まで取っていたため,これを書き換えると意図せず他の抜控を上書きしたり消去してしまう可能性があった(4月28日20歩で書いた消失不具合の原因だろう)。これは求頼文字列から取ることで回避した。
下書き抜控一覧についても,表示条件や領当てなど色々考えることが多かった。検討の結果,再描出下書きは,検索語無しの場合(上部メニュー同様)のみ輪郭一覧の上に表示(画面撮り),新規描出下書きは,他の抜控がある場合のみ新規描出フォームの上に常に表示させることにした(画面撮り)。邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発で決めた通り,一覧は省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化と抜控を溜め込み過ぎる懸念があるため見送った。抜控の溜め込みは性能低下,消失リスクの増大(あるいはそれを補う作業コストの増大)に繋がる。目障りになったら消化するようにしてもらいたい。
一番難しかったのは鍵仕様の設計だった。一応,鍵仕様変更時の更新方法は考えていたが,手間を考えるところころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所が見つかった。一時,鍵に仕様変更日時を含めることを考えていたが,これは複雑化を招くだけなので廃案とし,Aejs_DG_rev
に判別用の文字列を入れておくことにした。新規描出下書き抜控の鍵には自我知番を含め,自我の切り替えにも対応した。
その他,これまで描写のみ保存していたのを知名にも対応する,消去ボタン・復元ボタンを実装する,などこまごまとした問題を片付ける必要があった。
出振るい後,軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様の更新処理の失敗だった。領下で十分な手定めをしたつもりだが,本番環境では一部の鍵が1回の処理で更新出来なかった。結果的に,3回実行する必要があった。開発者通類で localStorage の内容を見ても交度を見返しても心当たりがない。
少し迷ったが,時間が経つにつれ重要性が急速に低下する部分なので,調査は打ち切ることにした。最も使用頻度の高い私や常連用者達が出振るい後も普通に使えていることから,深刻な問題は発生していないと判断した。今後,同様の処理を書く際の注意点として記憶しておく。

{希哲16年5月22日の開発 K#F85E/A-E74C-BEB2}

{希哲16年5月21日の開発 K#F85E/A-E74C-EEF9}

{希哲16年5月20日18歩 K#F85E/A-E74C-F5CF}

{希哲16年5月5日8歩 K#F85E/A-E74C-B5BA}

{希哲16年4月6日16歩 K#F85E/A-E74C-04AD}
まず,2日の開発で思い付いた全知検索ボタンの改良案を導入した(装体調整前・後)。
この検索ボタンの装体は,もともと全知検索演算子と連動させることを考えていたため,入力欄を切り離したようなデザインになっている。一体感とボタンとしての分かりやすさを両立させたもので方向性としては悪くない。ただ,若干無駄があった。2日の開発で合体選り手と同じ見せ方が使えそうなことに気付き,これでまとめた。
全知検索窓はデライト最初期に作り込んだ部分だったため,基本的にフォーム部品はこの装体を間に合わせで継承していたが,全知検索窓以外では過度に重々しく見える問題があった。先日,描出ボタンの改良で好感触を得たため,汎用的なボタン装体はそれに合わせてまとめることにした。
ボタン装体が軽くなったことで全体的な釣り合いも変わったため,一通り関連する装体調整も行った。設定ページ(装体調整前・後)もだいぶ良い感じになったが,特に扉(装体調整前・後)が大きく洗練された。これまでの重々しくごつい印象が,だいぶ軽く柔らかく見えるようになった。スクリプトの挙動がおかしい所もいくつか修正した。
新生デライト完成目前の丁度良い,然るべき時期に出来て良かった。
幅が足りず領当てが崩れることに気付いたため,幅狭領当てでは字数計をいったん非表示にすることにした。
`radial-gradient()`
}{作れた}{理想的な陰影}{簡単なようで}{実験していた}{画段}{色々な場面}...
{希哲16年3月28日の開発 K#F85E/A-E74C-5B9D}
KNEST 隠し実装の再開や金風といった出来事で中断していた昨年9月以来,初めての Aejs の出振るいを終えた。最初は微調整程度でとりあえずの出振るいを目指すつもりだったが,あっという間に下見機能と陰影付きスクロールが形になり,一応の「新輪郭選り手」が出来た。
外観・操作性ともに洗練された新輪郭選り手で日々の描出がより快適になることはもちろん,下見機能で手定め・領当て調整が大幅に効率化することによりデラング整備も加速するだろう。そもそも Aejs の出振るいが出来なかったことで前縁に関して出来ることも限られていたため,その障害が無くなったことが大きい。
新輪郭選り手
(今回の出振るい以前を「旧輪郭選り手」,以後を「新輪郭選り手」と仮に呼んでいる)
新輪郭選り手では,@oln.bld
に詰め込んでいた選り手関連の機能を @oln.edr_dln.bld
,@oln.edr_knm.bld
に整理し,複雑な機能を見通し良く管理出来るようになった。これにより,保守性はもちろん,全体として見触れが大きく改善した。
まず,これまで知名選り手は角丸長方形で,描写選り手は吹き描きに合わせた眼形で表示していたが,両方が開いている場合は「合体選り手」として眼形になるようにした(画面撮り:新規描出フォーム,再描出フォーム)。旧輪郭選り手では単独で開いた場合と外観が変わらず,調和感に欠けていた(画面撮り:新規描出フォーム,再描出フォーム)。挙動もより連動的になり,自然になった。
描写選り手の右脇に適当に付けていた取り消しボタンも,合体選り手では知名選り手・描写選り手を同時に閉じる機能が分かりやすくなり,見た目も洗練された。
描出ボタンも22日9歩の方針でまとめ,目障りにならないデザインを保ちつつ初心者にも分かりやすいものに出来た。
挙動面では,違了処理整備で若干表示のタイミングなどに出来ていたぎこちなさを解消出来た。外していた選り手の溶暗・溶明の動き付けも復活させ,滑らかに見えるようになった。
まだ様子見が必要だが,違了処理整備のあたりから出来ていた不具合の解消も期待出来る。特に,描写選り手が二重に開いたり,デラング記法を消去して再描出してしまう不具合が稀に起こるのが気になっていた。
今回の目玉となった下見機能は,思わぬ形であっさりまとまった。感触も良く,色々な場面で活躍してくれるだろう。
陰影付きスクロール
26日14歩に出来た陰影付きスクロールも同時に出振るいした(画面撮り)。下見機能にも有用と気付いたことで実装に踏み切れた。
背景色に溶暗していく「溶暗付きスクロール」として考え始めたのは昨年3月11日9歩だったが,空行が続くこともあり閲覧性も必要な描写部には不向きと気付いてからは,薄い陰影を付ける方向で実験していた。
これも簡単なようで調整が難しかった。陰影がかかる高さ・濃さ・画段の微妙な緩急の調整を繰り返し,さりげなく,かつ分かりやすい理想的な陰影がようやく作れた。一時,linear-gradient()
ではなく radial-gradient()
を使って中央に丸みのある陰影を試したが,交度部区などに重なった時に視認出来なくなるためやめた。
諸場舞覧などスクロールバーの出ない舞覧でスクロール可能であることが非常に分かりにくいという用合い上の欠陥がこれで解消した。スクロールバーの出る舞覧でもより直感的にスクロール可能であることが分かるようになり,効果は大きい。

{希哲16年3月28日の日記 K#F85E/A-E74C-51AA}
