作業中の当努の影響を受けないようにして,ここでいったん全体出振るい。手定め済み。
{希哲17年5月7日10歩 K#F85E/E74C-AE4F}
宇田川浩行{希哲17年4月20日の日記 K#F85E/E74C-03DF}
宇田川浩行今日から,ばら成しを意識して当努や日課などを片付けていくことにした。
ここしばらく,機能実装に一つずつたっぷり時間をかけることが多く,それはそれで得たものも大きかったが,そろそろリスクが許容出来ない時期だ。例えば,作業中のエクスポート機能実装に時間をかけて完成度を高めても,集客効果は高が知れている。何が起爆剤になるか分からないが,それをエクスポート機能に託すのは無理筋だろう。
新生デライトがもう仕上げ段階に入っているというのもある。未完当努が多過ぎた少し前なら,下手に作業範囲を拡げることで全て中途半端になりかねないという懸念があったが,今は残り当努が頭の中でだいぶまとまっている。10日の日記に書いたように,新生デライトに対する心境の変化があったのだろう。
{希哲17年2月5日14歩 K#F85E/E74C-AC49}
宇田川浩行埋め込み記法で埋め込まれている輪郭を描き直しても埋め込んでいる輪郭を描き直さなければ反映されない問題の修正,および一部機能で削除済み輪郭が取得出来てしまう問題の修正で終了。
前者の原因は単純に描写 HTML 隠しによるものだったが,報告を受け気付いた。
埋め込み記法処理も Dex_T
の外に出すかと考えたが,隠しの利用効率を考えると好ましくない。そこで,KNEST_T
に埋め込み関係の情報を持たせ,再描出時と輪郭削除時に描写 HTML 隠しを消去するようにした。これなら効率性と柔軟性を両立出来る。
作業中,削除済み輪郭が描写埋め込みや輪郭小窓から参照出来てしまう問題に気付き,これも修正しておいた。
dg_oln()
が b_del
を無視して輪郭情報を返すようになっていた上,一連の函数がそれを前提に実装されていた。これを機に違了処理も見直し,信頼性が向上した。
position: fixed
}{希哲16年12月16日の副日記}{誤表示}{誤移動}{再認識出来た}{どうにもならなそう}{数値を弄る}{ずれ方}{拡大率}(134){希哲16年12月16日の開発 K#F85E/E74C-8F21}
宇田川浩行前縁の問題をいくつも解消。特に諸場用合いはだいぶ良くなった。
輪郭小窓のスクロール不具合修正(Android 版 Chrome)
Android 版 Chrome で,全知検索窓を捕活している(ソフトウェアキーボードが表示される)時に輪郭小窓が表示されると全知検索窓までスクロールしてしまう問題を修正。iOS Safari 含め他の舞覧では再現しなかった。
とりあえず,touchend
で document.activeElement.blur()
を使って捕活を外すことにした。
輪郭小窓の誤移動不具合修正(iOS 版 Safari)
iOS 版 Safari で輪郭小窓が開く前に輪結先に移動してしまうことがある問題を修正。
iOS 版 Safari でのみ同じようにタップしても10回に1回程度の割合で生じる謎の現象だったが,実験を繰り返した結果,どうも click
事象が余計に発生しているようだった。
いったん click
事象を抑制し,touchend
で輪結先に移動するようにしたら,意図しない移動がなくなった代わりに,同程度の頻度でタップしても輪郭小窓が開かない問題が生じるようになった。条件はありそうだが,感覚的には全くの不規則なのでどうしようもない。
{希哲16年9月8日9歩 K#F85E/E74C-9254}
宇田川浩行{希哲16年7月21日の開発 K#F85E/E74C-7F30}
宇田川浩行無番輪符改良を完了した。これでデルンの長年の課題だった輪郭間輪結における知番依存が解消した。作業中,輪符補完機能についての閃きがあり,脳爆発が始まった。
輪郭選り手上での輪符補完機能は,省割キーあるいはカーソルのある輪括弧に表示されるボタンを押すことで開始することにした。省割キーは仮に Ctrl + { を想定しておく。
また,これを機にタッチ端末向けの記号入力ボタンも本格的に検討することにした。軽量標記言語を中心とした用合いの課題として記号入力の煩雑さがあったため,その解決策を兼ねる。
ここでようやく輪符補完機能の実装イメージがまとまった。最近のデライト開発では最大の暗部になっていた部分で,極めて大きな収穫と言える。
漠然と輪郭小窓実装に含めていた輪符補完機能だが,ここだけ実装イメージがまとまらなかった。一時,後回しにすることを考えていた理由だった。
原因は,輪符補完の自動開始を前提としていたことだった。自動開始となると入力中のデラングを正確に解釈する必要があるが,デラングの複雑性を考えると,交度の肥大化は避けられそうになかった。深刻な保守性の低下・請い手の低速化が懸念される。
更に問題なのは,そこまでの実装コストを払っても,用者体験の向上に繋がるとは限らないということだった。この手の挙動は好き嫌いがかなり分かれる上に環境との相性問題も大きい。多くの人が満足する水準にしようと思えばキリがない。
{希哲16年7月21日5歩 K#F85E/E74C-1AE2}
宇田川浩行{希哲16年6月11日の開発 K#F85E/E74C-D075}
宇田川浩行第二次知番改良,第零番節の削除,dg_kno_vac()
修正。
dg_kno_vac()
や周辺交度の整理,出場の整理は劇的に進んでいるが,あれこれ考え事も多くなり,明日の早朝出振るいは断念した。
作業中に輪数取得改良の方針が固まり,関連する新着確認機能などの実装イメージも急速に固まってきた。出場周りの見通しの悪さは輪郭削除や暗証語再設定など危険な機能実装の障害になっていたが,それも払拭出来た。
何より,「新括体採番法の完成」という意義があることに気付いた。実装こそ中途半端に放置されていて最初は頭を抱えたが,しっかり整理してみると,やはりこれ以上見通しが良く効率的な採番法は無いことが分かる。新括体採番法もデライト開発における大きな発明だったことを再確認した。
ae.js
}{NULL
}{Aejs}{希哲16年2月24日}{出振るい}{Aejs 整備}{希哲16年2月24日の開発}{希哲16年2月24日の進捗}(93)