「写し取り(写取)」は(コンピュータ操作上の)「copy」に対する宇田川の翻訳案。
一般的には,「切り取り(cut)」「コピー(copy)」「貼り付け(paste)」と訳されている。唐突にカタカナ英語が混じる違和感も,日本人の言語感覚からいえば許容範囲ではあるのだが,少し工夫して「写し取り」とすれば,十分意味も分かりやすく整列感を持たせられる。
また新生デライトの要件外ではあるが,ついさっき,急に実装イメージがまとまってしまった輪郭複製機能実装で終了。出振るい・手定め済み。
描写欄が空の状態の新規描出フォームで,自輪郭の輪符を知名欄に貼り付けるかドロップすると輪符から知名・描写が複写される。
複写に成功すると「複写完了」と表示,「複写失敗:自分の輪郭ではありません」と「複写失敗:描写が空ではありません」の違了表示も付け,自我知番の省略にも対応済み。使い勝手は非常に良好。
これまで通り「輪郭複製機能」と呼ぶべきかどうかは再考の余地があるが,眠気で考える余力が無いのでとりあえずは仮称としておく。「輪郭複写機能」の方がしっくり来る気もするが,「輪郭複製のための機能」という意味ではそこまで間違っていない。
輪郭複製機能については,昨年5月18日の開発で「知名・描写を複製して新規描出フォームに移動するボタン」として実装することを考えたが,その後の用合い改良を経て,抵抗感が募っていた。
輪郭を直接複製するような機能はやはり避けたい。手軽にし過ぎると誤操作や濫用の可能性が高まる。適切な手間という点で,新規描出フォームへの複写というアイデアは悪くなかった。ただ,現状の輪郭選り手が理想的にまとまっているので,極力ボタンのような要素を追加したくないと思うようになった。
さっきふと,「知名欄への輪符貼り付け」という案について考えていたら,これが急速にまとまってしまった。過去にも何度か脳裏をよぎった案だが,その時はいまいち気乗りしなかった。
貼り付け方式の最初の懸念は誤入力だった。復元ボタンだけでは心許ないので,知名が空であることを条件にしようとしたが,空の知名で書き始めることは少なくないので中途半端だ。複製したい輪郭を検索してから写し取り,貼り付けという流れを考えると,知名欄をいちいち空にしなければならないのは煩雑過ぎる。
間もなく,描写欄が空という条件なら全く問題ないことに気付いた。誤操作の懸念がなくなったので,ドラッグ&ドロップにも対応することにした。
もう一つ,自輪郭のみという制限を付けることにした。描写内の自我知番の省略に Aejs で対応するのが難しいという問題もあるが,濫用され著作権上の手溢れが増えることが予想される。他人の描写の扱いは慎重に,という意味でもこれくらいが適切だろう。
こうしてするする実装イメージがまとまり,一通りの機能を付けた実装も難なく完了した。余計な視覚要素を追加せず,それでいて直感的という,理想的な輪郭複製機能があっという間に出来てしまった。
深刻な不具合修正とボタン周りの挙動改良,輪郭削除ボタンでのみ輪郭削除が機能するように仕様を明確化・実装修正し装体調整(7歩)。これまでも輪郭削除ボタンを押下するのが輪郭削除の公式手順だったが,実装上は知名・描写を空にして送信すれば機能した。
不具合修正と輪郭削除ボタンの装体調整がきっかけで,やりたかった輪郭選り手の変更有無を表現する閉じるボタン(×ボタン)の装体イメージもまとまった。
検討中に新規描出フォームの細かい不具合も見つけたのでまとめて調整することにした。
第二次用合い改良でそれ以前にあった「知名欄にマウスオーバーすると自動的に捕活・全選択する」という機能が消えていたが,これを復活させるか検討。
特に意図したことではなく,当初は単に交度整理後の再実装を後回しにしていただけなのだが,これはこれで悪くないかもしれないと様子を見ていた。やはり写し取りに不都合を感じることが多く,全知検索窓との挙動の整合性もあるので復活に傾きかけていたものの,もう少し様子を見ることにした。
マウスカーソルが頻繁に横断する部分なので,捕活がころころ移ると別の問題が色々起きてくるだろう。これをやると描写欄にもマウスオーバーで捕活させたくなるが,そうなると誤編集の可能性も高くなる。その他,スクロールとの干渉など,相互作用を色々考えなくてはならない。
知名欄・描写欄の捕活に関する仕様検討の結果,ともに「マウスオーバーで捕活する」仕様を確定・実装した。出振るい・手定め済み。
仕様というほど明確なものではなく,時期によって実装上機能しないこともあったものの,デライト初期実装からのマウスオーバー時の挙動は,知名欄では捕活・全選択,描写欄では捕活,という方針だった。これは,実用上の都合というのも大きく,こうでなければ単純に描出効率が悪かった。
昨年9月までの第二次用合い改良中の交度整理で,知名欄の捕活・全選択は機能しなくなっていた。これは確か,中景輪符の事象を改良したことで干渉の懸念があり,再実装を後回しにしたという経緯だった気がする。もっと地味な描写欄の捕活は過去に何度か再実装した記憶があるものの,どの時点で機能しなくなっていたのかは曖昧だが,いずれにせよ,第二次用合い改良後はどちらもマウスオーバーでの捕活すら機能しなくなっていた。
もしかしたら,これはこれで今のデライトでは悪くないのかもしれないと少し様子を見ていたが,輪郭整備のように描出効率が重要な作業になると,クリックでの捕活はやはりまどろっこしく,鈍重に感じる。そこで最近はかつての挙動を復活させる機会を窺っていた。
懸念は,他要素・他機能との干渉や誤操作だったが,これは昨日の検討から急速に氷解した。今のデライトで,マウスオーバーで捕活が移動すること自体は前提のようなところがあるので用者体験に大きな悪影響はないだろうということ,むしろほとんどの要素がマウスオーバーに反応するのに知名欄・描写欄が無反応なことが直感性を損ねているとも言えること,スクロールとの干渉も実際の舞覧では生じないこと,誤編集の問題については,そもそも閲覧・編集用合いを切り分けていることが一定の保護機能になっており,更に取り消しボタンで変更有無が分かるようになることで大きく軽減されること,などの理由で,大きな問題はないという結論に達した。
そこでまず,知名欄の全選択も含めてマウスオーバーでの捕活機能を復活させてみた。ところが,知名欄の全選択については数十分で廃止を決定することになった。実装上の問題としては,選択状態がやはり周辺要素と干渉する。干渉しないようにマウスアウトで解除すると,今度は選択状態が意図せず解除されやすくなる。もっと問題なのは,誤入力で上書きしてしまいやすいということだった。全知検索窓では再検索のためにも上書きしやすい全選択状態が好都合だが,知名欄での利点は写し取りが素早く行えることくらいでさほど大きくない。
これは,今のデライトで,慣れ切ったこの挙動からいったん離れなければ気付かなかったことかもしれない。今のデライト市場戦略から考えても,熟練用者向け過ぎて採用出来ない。
次に,知名欄の全選択機能を外し,捕活だけにしてみると,これはむしろ想像以上に好感触だった。地味ながら,編集の軽快感は明らかに向上している。捕活さえしてくれれば Ctrl + A で写し取りも十分効率的に行える。今のデライトとの相性でいえば理想形とすら思えた。ここで正式な仕様として確定することにした。なお,捕活時に発生するスクロールは意図しない場合が多く考えられるため抑止する。
どこまで普遍的な現象か分からないが,常用している Linux の Firefox では,<textarea>
の選択状態を残して捕活解除すると,再選択のつもりが(未捕活状態のせいで)意図しない文字列ドラッグが発生しやすいため,これがなくなったのは個人的に嬉しかった。近頃多用している複数輪符の引き入れ欄への写し貼りで障害になっていた。
とにかく,第二次用合い改良後に残っていたもやもやしたものを払拭出来たのは大きかった。
領下手定め環境で概ね問題なさそうだったため,新生全知検索整備の中間出振るいに踏み切った。首尾良く完了し,大成功だった。これにより後縁も最新の状態で同期され,自由自在な開発体制を取り戻した。
21時30分出振るい作業開始。断帯は21時30分から約5分。23時頃までには一通り点検・不具合修正を終えた。
その後,動作は極めて安定している。dg_fnd()
への輪数取得処理組み込みは今回初出振るいとなるが,高速化効果は,毎回輪数計算が必要になる場合の検索で数十ms(求頼1回分)の短縮なので体感速度向上はあまり期待していなかった。しかし,意外と検索時の軽快感が増している気がする。最初はプラセボ効果に近い開発者心理かと思ったが,自分の全知検索歴と検索頻度を考えれば感じ取れてもおかしくはない。嬉しい誤算だった。
安心して後縁に手を入れられるようになったので,手始めに,輪符が生成する輪結で,第零番節付き知番がそのまま輪結先などに反映されてしまう問題を修正した。
これにより,輪符の知番が K#9-XXXX/A-YYYY
と記述されていても,輪結先は第零番節の削除をした /?fg=KNo.XXXX/YYYY
や /KNo.XXXX/YYYY
となる。第二次知番改良を経て司組が生成する知番はこれで統一するようになったが,デラングでは大量にある第零番節付き輪符が第零番節付き輪結を生成していたため,クロール効率への悪影響が懸念された。出与え属性を通して輪郭小窓の知番表示にも反映されていたため,用合い上の問題もなくはなかった。
とりあえずは量が多い基本形の輪符と重い強調輪符でのみの対応。
ついでに,再置換問題などで混乱していた時期にいったん無効化していた知番単独での輪結化も復活させた。知番接頭子の越化参照化で上手く行った。
装体は基本的に URL と同じにしたが,文字サイズは0.9emでも若干小さく感じるため1emのままにしておいた。
16日の開発の「写し取り機能によるがたつき不具合修正」が間違っていたため再修正。
17日あたりから Mac 版 Safari で写し取り機能が働かないという不具合報告を受けて調査したところ,iOS 版 Safari でも働いておらず Safari 共通の問題だったことが判明した。iOS 版 Safari では手定めしたつもりだったが,貼り付け手定めまでしていなかったらしい。
16日の開発での修正が原因であることは明らかだったため,いったん修正内容を取り消し12時20分頃には復旧。改めてがたつき不具合の調査に入った。
当初,一時的に使う入力要素の高さによる問題と誤認して height: 0
にしたが,これが Safari の制限にかかったか(height: 1px
などでも変わらず)。そもそも position: fixed
にしているので高さでがたつくとは考えにくかったが,Safari 固有の描画バグかなにかだと思っていた。
よくよく観察してみると,このがたつきは要素の描画というより,入力要素捕活時の小さなスクロールによるものらしかった。ただ,手持ちの iPhone 7 では,非 PWA の Safari 縦向きで全知検索窓が画面に入る位置でしか再現しなかった。PWA や横向き,LambdaTest の iPhone 12 ではそれらしい挙動はみられず,特定条件下で Safari のウィジェットと干渉しているような気がした。
こうなるとどこまで普遍的な現象か分からないので諦めかけたが,そもそも一瞬とはいえ入力状態に入るのが間違いということに気付き,捕活時は読み取り専用にしてみたら再現しなくなった。結果的に,おまじないのようなものよりずっと理に適った解決策が見つかって良かった。
現状「コピー完了」は写し取り処理実行後,無条件で表示されるようになっているが,これが手定め時に間違った安心感を与えていたのは反省点だ。不具合を除いて写し取り自体の違了は極めて稀であり,失敗したとしても再試行コストは限りなく小さいため実用上の問題ではなかった。
写し取り機能の手定めでは貼り付け手定めまでするようにしていたが,16日の開発ではあれこれ細かい作業をしていたので抜けてしまった。「コピー完了」を確認した時点で安心してしまったのだろう。
この作業で久しぶりに LambdaTest を使った。また定期的に舞覧手定めの時間を作りたい。
待っ読小窓にも輪郭一覧動的更新で消えない問題が残っていたため修正。出振るい済み。