filter
}{ダークテーマの様子・輪郭選り手}{ダークテーマの様子・輪郭小窓}{ダークテーマの様子・Mermaid}(170){希哲17年2月12日の開発 K#F85E/E74C-A440}
宇田川浩行出振るいと一通りの手定め・調整を終え,ダークテーマ実装が一段落した(22歩)。実質的な機能公開は設定ページのテーマ切り替えボタンを解放した24時45分頃。
元々持ち辺が高くなかったこともあり,早くて機能公開は一週間後,満足出来る品質に達するのは数ヶ月後かという感覚でいたが,昨日「暗いデライト」の真価に気付いて集中的に調整を進め,ほとんど理想的なダークテーマが出来てしまった。今後は実際に使いながらの微調整程度で十分だろう。
ダークテーマの有用性については個人差・環境差が大きいが,それだけに選択肢が出来た意義はデライトにとって大きい。装体整理兼ダークテーマ実装を通して装体書の全体的な見直しが進んだことも大きな収穫だった。
{希哲16年12月18日の開発 K#F85E/E74C-8AE4}
宇田川浩行新生全知検索整備・中間出振るい
領下手定め環境で概ね問題なさそうだったため,新生全知検索整備の中間出振るいに踏み切った。首尾良く完了し,大成功だった。これにより後縁も最新の状態で同期され,自由自在な開発体制を取り戻した。
21時30分出振るい作業開始。断帯は21時30分から約5分。23時頃までには一通り点検・不具合修正を終えた。
その後,動作は極めて安定している。dg_fnd()
への輪数取得処理組み込みは今回初出振るいとなるが,高速化効果は,毎回輪数計算が必要になる場合の検索で数十ms(求頼1回分)の短縮なので体感速度向上はあまり期待していなかった。しかし,意外と検索時の軽快感が増している気がする。最初はプラセボ効果に近い開発者心理かと思ったが,自分の全知検索歴と検索頻度を考えれば感じ取れてもおかしくはない。嬉しい誤算だった。
輪符と知番の輪結改良
安心して後縁に手を入れられるようになったので,手始めに,輪符が生成する輪結で,第零番節付き知番がそのまま輪結先などに反映されてしまう問題を修正した。
これにより,輪符の知番が K#9-XXXX/A-YYYY
と記述されていても,輪結先は第零番節の削除をした /?fg=KNo.XXXX/YYYY
や /KNo.XXXX/YYYY
となる。第二次知番改良を経て司組が生成する知番はこれで統一するようになったが,デラングでは大量にある第零番節付き輪符が第零番節付き輪結を生成していたため,クロール効率への悪影響が懸念された。出与え属性を通して輪郭小窓の知番表示にも反映されていたため,用合い上の問題もなくはなかった。
とりあえずは量が多い基本形の輪符と重い強調輪符でのみの対応。
{希哲16年1月23日4歩 K#F85E/E74C-6C79}
宇田川浩行キーボード記法に関しては,改めて [_X_]
記法を中心にしていく方針で再確定した。また,[_X_] + [_Y_]
を一つの記法として扱うことも明確化した。
[_X_]
記法を導入して一件落着かと思ったキーボード記法だが,その後,少し迷いが生じていた。
この記法がボタンらしく見え過ぎるせいで,ウィジェットのボタンにも応用出来る「ボタン記法」のようなものも可能なのではないかという欲が出てしまっていた(AsciiDoc にはボタンやメニューを表現出来るマクロがある)。それが可能なら,[_X_]
をキーボード記法とすべきではないかもしれない,という気がした。
ただ,[_X_]
をキーボード記法を一般化した「ボタン記法」にしようかと考えてみたところで,そもそも千差万別の外観を持つウィジェットボタンを抽象的に表現出来る装体が存在しないことに気付いて廃案となった。確かに記号としてみるとボタンらしいのだが,ボタンらしい装体を付けようとすると全くイメージと違うものになってしまう。これではあまり意味が無い。あくまでも言語的に扱うか,視覚的に扱いたければ画像素材を行内埋め込み記法で挿入するのが適切だろう。
そう考えると,キーボードのキーに使う装体がキーの記号としてちゃんと機能するのは特殊な例だ。
<script>
}{@mbd.Tw
}{希哲15年6月17日の進捗時限}{希哲15年6月17日の進捗}{希哲15年6月17日}{埋め込み部区実装}(28){希哲15年6月17日16歩 K#F85E/E74C-A343}
宇田川浩行mouseout
}{希哲15年3月5日の開発}{autocomplete="off"}{再入力}{発生頻度}{ブラウザの欠陥}(42){希哲15年3月5日2歩 K#F85E/E74C-2104}
宇田川浩行手元の Firefox で,全知検索窓の補完窓が表示される際,マウスポインタが境界にあると入力の度に再捕活が発生し事実上入力不可能になってしまう不具合の修正に入る。
全知検索窓へのマウスオーバーで全選択状態になるデライトの仕様と,ウィジェットにマウスポインターが乗ると mouseout になってしまうブラウザの挙動との相性の問題で,最初期から認識していたが,ブラウザの欠陥に近い問題と感じていたことと微妙な発生頻度だったことで放置していた。
マウスオーバーで全選択になる仕様も再検討したが,全選択になった方が写し取りや消去して再入力といった操作が効率的に行えるため,これは維持することにした。
autocomplete="off" にしてブラウザの補完窓を使わないようにすることも考えたが,これはこれで便利なこともあるため,独自補完窓の実装までは利用することにした。
途中で終了。
{希哲15年2月13日6歩 K#F85E/E74C-F2A8}
宇田川浩行いったん終了。
無名輪郭の描写だけを編集・保存した際,知名に「あれ」が設定されてしまう問題,他輪郭の知名欄を開いても読み取り専用になっていない問題,輪結の URI 符号化が出来ていなかった問題,その他表示上の調整を終えた。
全て実用上大きな問題ではないが,微妙な違和感や使いにくさを感じさせる要因ではあった。
他輪郭の知名欄は開けても仕方ない気もするが,将来的に特殊な記法を導入する可能性があり,写し取りしやすいという実用上の利点も一応ある。
知名欄を開いて閉じるだけで更新されてしまう問題だけが気になるが,これは近いうちにやる同期の見直しとまとめることにした。
ここでふと,時印更新用のボタンは描き直しボタンで表示させるようにすることを思いついた。
自輪郭の更新日時の記号をボタンに変え,押すだけで時印更新出来るという方向で検討していたが,想定される使用頻度の割に目立ち過ぎ,誤操作を誘発しかねないという問題があった。
描き直しボタンを輪郭の更新にかかわるウィジェットを全て表示するボタンと捉えれば,時印更新ボタンを表示させる機能を兼ねさせるのも理に適っている。