{需要がある}{地味ながら}{厳密に考える}{見分けが付く}{開いている時}{実装出来た}{現仕様}{万能ではない}{resize: vertical}{高過ぎず}...=}(116)

{希哲16年3月30日の開発 K#F85E/E74C-7061}

描写欄高さ問題きっかけ自動リサイズ機能字数計実装出来た。ほか装体調整など。

出振るい済み

自動リサイズ機能

旧輪郭選り手では,描写欄出放り高さ新規描出フォーム10em再描出フォーム15emとしていたが,新輪郭選り手ではたまたま15em統一されていた画面撮り10emでは長文書きにくいのでこれはこれでいいかと思ったが,やはり新規描出フォーム一言だけや知名だけの描出使うことも多いためこの高さでは邪魔臭い

ここで,予てからぼんやり検討していた自動リサイズ機能導入考えた一応 resize: vertical設定してあるが,万能ではない10emから20em程度までの範囲で,改行毎に自動リサイズさせる。導入予定字数計では字数情報必要になるため,一緒に行数保持させることにした。

実際に試してみると,1em刻みでも2em刻みでも違和感があったため,10emから19emまで1.5em刻みリサイズするようにした画面撮り初期状態最大自動リサイズ19emだと個人機でも低過ぎず高過ぎずスマートフォン縦向き柔品キーボード表示させてもちょうど収まる程度の高さになる。折り返し多い1行もありうるため,厳密にするなら字数考えるべきだが,とりあえずはこれで様子を見ることにした。

再描出フォームに関しては,さほど目立つものでもなく,描写部高さ合わせて描写欄開くようになっている現仕様悪くないので,現状維持様子見しておく。

字数計

字数行数保持出来たことで字数計難無く実装出来た描出ボタン時印左側邪魔にならないように表示させてみた字数計の様子

下見字数分けようかと思っていたが,下見開いている時下見字数置換すれば十分であることに気付いた一応見分けが付くようにに「」を付けるようにした。

これも,厳密に考える特殊な文字符号などを考慮する必要があるが,キリがないのでとりあえず .length による概算でよしとしておく。

字数計は,地味ながら意外に需要があることを市場調査通して知った自分でもたまに欲しくなることがあった。

{Aejs 整備}{色付き}{有効時}{抜控機能実装}{下見タブ}{下書きタブ}{両立させる}{違和感がある}{希哲16年3月20日}{開発}...=}(72)

{希哲16年3月20日の開発 K#F85E/E74C-0B0E}

{文字サイズ}{進捗記録}{目立たな過ぎる}{装体の調整}{読みにくさ}{短い URL}{事情が異なる}{ちょっと長い}{文書の傾向}{検討していた}...=}(94)

{希哲16年1月19日1歩 K#F85E/E74C-5396}

デライト装体調整URL 装体調整終了

直書き URL<a.URI>font-size: 0.9em等幅フォントにしたURL 装体調整前後字間無し昨年6月30日の開発からだが維持する。

直書き URL のある描写読みにくい問題はずっと以前から感じていて,何度か調整しているが,一昨日の開発中にふと,「文字サイズ小さくしていない」ことに気付いた

昨年6月30日の開発字間無しにしているが,等幅フォントにして変に目立ち過ぎるという理由したりもしている。この時になぜ文字サイズ小さくするという発想がなかったのか不思議だ。他にも問題山積していて思考時間割けず灯台の下まで目が行かなかったか。

今回<kbd><code>装体について考えていたところだったので,その関連気付けたのだろう。

文字サイズはやはり0.9em丁度良い0.8emにすると長い URL はともかく短い URL提示する時に今度は目立たな過ぎる


これにより,十分凝縮されメリハリが付いたので,予てから検討していた長い URL の省略については保留とすることにした。

長い URL の省略は,簡単なようでいざ導入しようとすると意外と難しい問題がある。

まず,デライト上文書の傾向からいっても,「ちょっと長い」程度の URL省略したくない。URL全体情報として有用場合しばしばある。このあたりはマイクロブログなどとは事情が異なる

では,どこで省略すべきかという問題になるが,長い URL許容すればするほど比較的短い URL読みにくさ解消されないというジレンマがあった。これは装体の調整解決した。

そもそも輪結記法[ ... ]もあるので,現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx のような省略記法導入してもいい。

ただ,パーセント符号化復号はしたい。これは昨年3月22日2歩決めていたことだが,少し面倒臭い部分がありいまだに実現していない。

{進捗記録}{廃止}{希哲15年12月17日の開発}{kn+/}{持たせた}{将来的に}{バイナリ実装}{スクリプト実装}{無拡張子}{必要に応じて}...=}(63)

{希哲15年12月17日2歩 K#F85E/E74C-7E64}

知機駒手実装整理終了

+ 接尾子使った台録構造について見直した結果これまで必ず置いていた実行譜類への疎輪結のみ「必要に応じて」とすることで概ね現状維持となった。

アンダースコア略記法の廃止により,今後kn+/foo+/bar.sh のような台録構造副駒手管理することになる。いっそのことこの + 接尾子廃止していいかと思ったが,kn+/foo という無拡張子疎輪結使うことでスクリプト実装.shバイナリ実装.x切り替え容易になるという狙いがあり,これはこれで捨て難い設定譜類より直接的分かりやすいし,最上位knkn+/ になるのが自然なのでそれに整合的でもある。

将来的に膨大な副駒手追加することを考えて持たせた柔軟性だが,これまでの実装では無拡張子疎輪結を通して副駒手探索していたため,常に副駒手疎輪結しておく必要があり,スクリプト実装しかない現状ではただ煩雑なだけだった。これを省けるようにすれば柔軟性維持しながらかなり見通しが良くなる

=}
{開発}{開発記録}{デライト}{見てもらえる}{見れる環境}{上信時}{大した}{代替形式}{写真投稿者}{WebP 統一}...=}(31)

{希哲15年12月3日の開発 K#F85E/E74C-0931}

9月3日の開発では見送ることにした添付画像WebP 統一だが,写真投稿者という立場改めて検討し,ここで統一してしまうことを決めた

デライト画像素材などは代替形式用意することに大したコストはかからないため現状維持として,添付画像に関しては原則として上信時WebP 変換する。

文字献典基礎にしていることはデライト強みなので,ここは割り切り,見れる環境見てもらえればいい,と写真投稿者という立場でも思えたことが決め手だった。

=}
{進捗記録}{輩符}{デライト}{知番}{希哲15年10月23日の開発}{番号無し}{一対一}{抽象的な}{付けている}{ウェブ関連}...=}(62)

{希哲15年10月23日7歩 K#F85E/E74C-1717}

捌き手整理着手する前に,保手名命名規則と今後の命名方針について整理して終了明文化していなかった規則再確認も兼ねて。

保手名はあくまでも抽象的な役割を表すものなので,役割が変われば保手名も変える保手名捌き手一対一対応している必要もない。

番号捌き手固有のものではないので,主要なものから順に付けていく。これまで欠番放置してしまうことが多かった。個々の捌き手確実に示すためには知番を使うべきだろう。

番号無し保手名代表的役割を持つことを示す

番号の前に付けている輩符は無くしてもいいかと思ったが,番号を視認しやすい利点もあるため現状維持としておく。特に,abc-def-1 のように保手名複合化した時にも分かりやすい。昔も同じことを考えていた気がする

現在ウェブ捌き向けの汎用保手名として sss をそのまま使っているが,ブランディング一環として表に出さなくなった時点で実用上意味は無いため,いったん www改めることにした。代わりに,デライトウェブ捌きを表す dlt導入する。

ウェブ関連www-1(兼 dlt-1)と db-1 にいったん集約することになる。

{開発}{開発記録}{選り手}{下見ボタン}{下見機能}{Meson}{新生デライトの要件}{日本語表現}{プレビュー機能}{開閉状態}...=}(109)

{希哲15年8月1日の開発 K#F85E/E74C-7A28}

新生デライトの要件

もう考えていても仕方ない段階に来ているので,とりあえず雑に書き出しておく。

舞覧手定め環境整備

舞覧手定め環境整備一環として,SLFSChrome59最新版92更新

3月15日7歩でも試みているが,その時は libxkbcommon不足失敗依存性地獄懸念して中断した。

libxkbcommon引装には MesonNinja の引装が必要で,Meson と Ninja には Python 3 の引装が必要だったものの,それ以外に直接必要なライブラリはなく,意外とあっさり更新出来た。

これで SLFS では FirefoxChrome最新版が使えるようになり,手定め用iPhone 7近日中手に入る予定なので,舞覧手定め環境整備はここで一段落とする。

Android 端末向けの舞覧手持ちのスマホで,Edge 含め,Windows 向けの舞覧Windows 仮想機で使える。

実機仮想機では主に最新舞覧を使い,古い舞覧などは LambdaTest などのサービス利用すれば十分だろう。

輪郭選り手抜控機能整備など

描き直し選り手同期するように調整

とりあえず,選り手が開いている場合に内容同期させるようにだけしておいた。これで複数窓で同じ輪郭の選り手が開いていても混乱しにくくなり,内容が長い場合には複数窓で別々の箇所を編集することも出来るようになった。

現状,抜控のある選り手はページ読み込み時に開くようになっているが,閉じている場合でも別窓で抜控が出来た場合は開いたり,別窓で閉じた場合は自動的に閉じたりと,開閉状態同期もしようかと思っていた。これは止めておいた。

開閉状態の同期はしない方が,一方の編集用にして,一方の窓を確認用するなどといった応用の可能性が広がることに気付いた

現状では描き直し完了選り手閉じる機能的に一緒になっているが,複数窓有効活用を考えると保存と閉じるで分離すべきか。取り消しボタンを閉じるために使うかと思ったが,操作性を考えると,今の完了ボタンを保存・閉じるの二段階にする方向が良さそうだ。

そんなことを考えているうちに,保存せずに換配後プレビューが出来る機能についても検討し始めた。概念操作複雑化を避けることを考えるなら,完了ボタン機能現状維持プレビュー機能本命かもしれない。

プレビュー日本語表現は「確認」が分かりやすいだろう。内部的には「換配確認機能」や「確認ボタン」と呼んでおくことにした。

=}
{Aejs}{進捗記録}{defer 属性}{希哲15年4月1日の開発}{描画速度}{二度手間}{link rel="preload"}{速度差}{DOM 構築}{Document.readyState}...=}(53)

{希哲15年4月1日17歩 K#F85E/E74C-FE68}

Aejs@icl() とその周辺見直し

いったん終了。

デルン初期実装からか,@icl() では Document.write() 相当の @doc.wr() を使って script 要素を書き出していたが,これは様々な面で好ましくない。こんな実装にした経緯失念したが,装体書で同じようなことをする @apd_ss()@elm.bld..apd()Node.appendChild())を使っているところをみるに,テンプレート上で書き出し位置を指定しやすいといった理由があったのだろう。

特に,昨日まで Aejs にあった干渉不具合を回避するのに有用ではあったが,もはや不要なのでここで周辺とともに整理しておいた。

まず,@icl() を @elm.bld..apd() を利用した実装にし,スクリプト調整を行なった。AdSense より前の位置に配置していたため,これを body 要素末尾のその他ライブラリ前に移動した。非同期になったことで DOMContentLoaded が終わっている可能性があるため,Document.readyState を利用して DOM 構築完了後であれば即実行する処理を @() に加えた。

更に,各スクリプトに defer 属性を付け,直書きしている部分は addEventListener() で DOMContentLoaded を待ってから実行するようにした。ここはスクリプトを通さず捌き手側で直接書き出してもいいかと思ったが,試してみたところ大して速度差が無かったため,現状維持とした。

更に,link rel="preload"導入,ついでに cfg.vs で設定していた隠し破りテンプレート側で設定し,@icl() や @apd_ss() に引数として渡すようにした。テンプレート側で直接記述している URI に利用出来ず,修正作業でよく二度手間が発生していた。

ここまでの作業で体感的描画速度向上が見られた。ただし,速くなった分描画過程が見えてしまうようになったため,明日装体書調整を行うことにした。

未出振るい

=}
{進捗記録}{部区}{デライト高速化}{Dex}{希哲15年3月10日の開発}{つづきボタン}{描写後略機能}{描写後略}{部区の切り分け}{デラングの問題}...=}(60)

{希哲15年3月10日2歩 K#F85E/E74C-93F5}

デラング整備

途中で終了。

Dex 実装にあたって,任意文字数を基準とした描写後略機能導入を考える。

現状,描写は全て出力しているため,通信処理効率の点でかなり無駄がある。

描写後略は単に特定の長さで切ればいいというものでもなく,部区途中や残り部分が短か過ぎる場合などにも対応する必要があり,部区の切り分けが出来ていなかったデラングの問題でもあった。

Dex によってこの問題解決見通しが立ち,デライト高速化にも寄与するだろう。

実装としては,解析時に指定文字数を基準に多少の調整をして目印を付けておき,それを元に出力し分ける形になりそうだ。

用合い上は,基本的には現状維持で,描写部が長過ぎた場合に「...つづき」という形のつづきボタンを表示,押すとその場で残りが展開される,という形を想定する。

輪郭ページへの輪結で済まそうかと思ったが,一覧しながら少し内容確認したいだけでも画面遷移発生するのは若干煩わしい

そもそも現状の高さ固定スクロールさせる方式苦肉の策でもあったため廃止検討してみたが,これはこれで有用なので維持することにした。

最初に取得しておくべき献典の長さと,輪郭一覧で表示しておきたい長さは必ずしも一致しない。一覧性を損わない長さに描写そのものを切り詰めると内容が掴みにくくなり,つづきボタンが無駄に押される可能性が高い。

描写部の高さの2〜3倍は取得しておいていいだろう。

スクロール方式なら展開しっぱなしでも邪魔にならない,というのも大きい。

{現状維持}

{}