Aejs の交度整理も進めつつ,前後景輪数増減表示を前後景部同期処理に組み込んだ(様子)。いったん出振るい・手定め済み。
これにより,動的な輪括操作では,操作の結果として生じた前後景輪数の増減値を +
と -
で,増減が無い場合は ±0
で,読み込み中は ±?
で表示するようになった。
増減表示は太字にし,元の数字との間に半角スペースを入れた。最初は太字だけで十分かと思ったが,意外と視認しにくかった上に,-
で 2-1
のように表示すると一見意味が分からない。
小さな変化で実装も単純ながら輪括操作の感触が非常に良くなった。
ついでに,前後景輪数表示も3桁カンマ区切りにしておいた。ページャーなどでは3桁カンマ区切りだったが,ここだけ単純な数字列で微妙な不統一感があった。
これまでは単純に最新の状態に置換するだけの同期処理だったため,操作の効果が分かりにくいという問題があった。
特に,引き入れ・引き外しされる輪郭の時印が古く前後景部に表示されていない場合と,何らかの問題で同期に時間がかかっている場合は無反応に見えてしまっていた。複雑な輪括操作をしていると,どの輪郭に何をしていたか分からなくなってしまう問題もあった。
問題はデライト最初期から認識していたものの,もっと派手で複雑な表示を考えていたせいでなかなか実装イメージがまとまらなかった。輪括数も高が知れている初心者の場合は見た目の変化が大きいため分からなくはないし,慣れた用者も表示輪数の変化で分からなくはないので放置してきてしまった。
例えば,最後に引き入れした輪郭を分かりやすく表示しておくという案があったが,様々な場面で直感的かつ邪魔にならないようにするには実装コストが無駄に高くつく。特に,引き入れ欄の複数知番対応以後は現実的ではなくなっていた。
他方,昨年8月21日の前後景時印導入以後,前後景輪数が極端に多い輪郭の前後景部同期にやたら時間がかかる問題が発生していた。これ自体は例外的な輪郭でのみ起こることで仕方ない面もあり,捌き手増強で対応することを考えているが,読み込み中くらいの表示は欲しかった。そこで,前述案などを補助するものとして考えていた増減表示に読み込み中表示を兼ねさせて一時凌ぎすることを考え始めた。だんだんこれだけで十分な気がしてきて,9日の開発で増減表示を中心とした引き入れ用合い改良案がまとまった。