{進捗記録}{十分}{進捗}{希哲17年5月6日の開発}{希哲17年5月6日の進捗}{希哲17年5月6日}{制御したい}{1つの}{座標指定}{当面は}(91)

{希哲17年5月6日10歩 K#F85E/E74C-DDBB}

進捗時限記録中略

動的引連 SVG アイコン実装

途中で終了

SVG スプライト手法取り入れSVG アイコン定義icn.svg集約することにした。

SVG 出与えAejs組み込んで直接挿入してしまうことを考えていたが,舞覧隠し適切な分離出来なくなる要素の再利用必要な id 属性使いにくい,といった問題があった外部 SVG<use>利用すれShadow DOM になるので,id 属性衝突などを気にせず要素整理しやすくなる

スプライト画像として background-image利用しやすいというのも大きい:targetフラグメント識別子利用して表示要素変化させる技術があることを知ったが,舞覧によっては効率的に隠し出来ないことがあるらしく,今回は見送った<view>使えればいいが,Safari対応難がある当面は古典的な座標指定行くことにした。

アイコン制作では,アイコン並べて全体ばら成し見ながら調整することが多いため,見本兼ねられるのも便利だ。

SVG スプライトだけで十分かもしれないと思いかけたが,<use> 1つでも若干冗長な上に,1つのアイコン要素細かく制御したい場合<use>複数必要になるため,やはりスクリプトでの補完欲しい

{進捗記録}{方向}{}{以前}{描写}{進捗}{デライト}{希哲17年1月15日の進捗}{希哲17年1月15日の開発}{希哲17年1月15日}(116)

{希哲17年1月15日10歩 K#F85E/E74C-36C0}

進捗時限記録中略

ついでに新規描出フォーム固定機能についても検討して終了

こちらは「限りなく廃案近い保留」となった。


全知検索窓固定機能同様デライト最初期実装削除したものだが,これは広告との相性以前に,用合いとしていまいちだったということが大きい

新規描出フォーム固定出来れば,輪郭一覧眺めながら描写書くことも出来便利違いない,と素朴な期待から実装してみたが,これが帯に短し襷に長しという感じ思いのほか使えなかった

大きな原因は,ページ遷移までのちょっとした固定されるだけ,という中途半端さにあった。あちこち飛びながら作業しているといちいち解除されるので,自然に使わなくなっていく

これに対処しようとすると画面分割機能近い大掛かり仕掛け必要になる画面分割機能何度も検討したが,やはりデライトには過剰判断して,複数窓使いやすくする方向単純性保ってきた今考えてもこれは英断だった。

自動ページ展開輪郭一覧動的更新がある今なら当時よりは使いようがあるかもしれないが,その分,ページ遷移条件分かりにくくなっているので,かえってストレスかもしれない。

複数窓使いにくいスマートフォンなどでも,新規描出フォーム柔品キーボード画面ほとんど占有されるため恐らく使いものにならない当時諸場使える状態ではなかったので想像ではあるが,複数タブ使う方がマシだろう。

結局構造的にデライト向きではないのだろうと思うが,急いで結論を出す必要もない。そのうち適当な活用法見つかればいいし,見つからなくても問題ない。というわけで,しばらく放置しておくことにした。

迷い一つ消えたのは収穫言える

{進捗記録}{希哲16年}{進捗}{デライト}{希哲17年1月15日の進捗}{希哲17年1月15日の開発}{希哲17年1月15日}{下がれば}{済みそう}{かからず}(118)

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

進捗時限記録中略

新生デライトの要件ではなかったが,デライト最初期実装削除してからずっと保留状態にあった全知検索窓固定機能実装イメージ急速に固まったのでまとめ終了

全知検索窓では,下スクロール隠れ上スクロール現れる固定表示採用することにした。

昨日寝る前に Android 版 Chrome触ってい思いついた上スクロールツールバー現れる以前にもこの方式検討した記憶があるが,その時流してしまった昨年新規描出フォーム固定機能とともに大きく検討を進めたことがあった開発記録ので,時期的噛み合わせだろう。


いったん削除した理由その後復活させられなかった理由主に二つあった。

一つは,広告との相性問題だ。AdSense では広告固定メニューのようなものが被ることもグレーとされている。実際には悪質でなければそこまで厳しく対応されることはないだろうが,広告頼みデライトではわずかなリスクでも避けたかった

もう一つは,画面広く使いたい場合邪魔になることがあり,必ずしも便利ではなかったことだ。当然スマートフォンのような小型端末ではこの問題顕著になる

昨年検討では,広告近付いた隠すようにすることと,表示領域の高さ十分ではない場合固定機能無効にすることでこれらの問題回避する方針固め復活向けて一歩前進した。しかし,実装調整煩雑さ対して必要性高まらずここまで実作業至らなかった

今回採用を決めた方式なら,調整手間ほとんどかからず交度半分くらいで済みそうだ。無くてもそこまで困らない機能ではあるが,これくらい実装コスト下がれば優先順位上げられる

{開発}{開発記録}{最短}{}{}{知番}{Aejs}{希哲16年6月17日}{完成の域に達した}{表記的}(146)

{希哲16年6月17日の開発 K#F85E/E74C-9EA6}

自我知番省略機能実装終え第二次知番改良完了とした20歩ここでやっておこう思ったのも,途中で第零番節の削除転換したのもあまりにだったが,その割には終始円滑にり,収穫想定はるかに越えて多大だった。全体として大成功言っていいだろう。

第二次知番改良経て知番表記的にも内部的にも完成の域に達した。あとは仕様実装微調整繰り返していく

まず,当初の目的だった知番の簡略化言うまでもなく大きいこれまで一般のデライト用者最短でも K#9-XXXX/A-YYYY という15文字知番輪郭扱う必要があった。それが第零番節の削除によって11文字K#XXXX/YYYY になり,自我知番の省略によって7文字K#/YYYY になった。知番表記仕様に関しては理想的な形だ。

第零番節の省略」から「第零番節の削除」に転換したことで,知番周りの交度出場整理劇的に進んだ。これにより,効率性保守性大幅に向上したのはもちろん,「新括体採番法の完成」という思わぬ収穫繋がった未実装だった自動知番拡張もここで実装出来た今のところ第二番節しか使っていない状況だが,そろそろ必要かという丁度良い時期だった。

波及効果想定以上に大きかった出場見通しの悪さなどが障害になっていた機能実装に関しては大幅な所要時間短縮見込めるようになった特に見通しが悪い課題だった KNEST 隠し出与え構造がこの期間固まり,一気に実装可能性高まった自我知番省略機能Dex との連携必要になったことで,他の記法でも活かせる出与え共有機構整った。これが無番輪符改良などにも繋がっている

将来的に長い知番増えた時のための「知番略記法」を中心とした第三次知番改良方針固まった。この長年の課題にも解決の見通しが立った。

一つ見送ったこともある。自我知番省略された知番写し取り時自我知番付け自輪郭描写欄などへの貼り付け時自我知番の省略をする4月8日の開発記録,というのは,やはり用合いとしては理想的盛り込みたかったが,今回見送った。このあたりの事象Aejs整理中なので,どうしても場当たり的交度になってしまう。他輪郭素出から写し取りたい時や,外部媒体厳密な知番貼り付けたいという時には便利だが,現時点必要としている人少ない共有目的なら共有ボタンがある。交度整理しながら適当な時期実装することにした。

{進捗記録}{}{右開き}{右矢印}{}{十分}{}{記号}{自然言語}{進捗}(171)

{希哲16年2月18日13歩 K#F85E/E74C-E223}

進捗時限記録中略

前後記法」として検討していた記法を「前次記法」に改め仕様再検討して終了

<- 前 | 次 ->

<- 前
次 ->

<- 前のみ

次のみ ->

以上のように,<- 前 | 次 ->基本形とし,改行区切り<- 前次 -> のみでの記述可能にすることにした。

読み込み中...
{Markdown}{進捗記録}{}{}{}{右寄せ}{}{末尾}{記号}{進捗}(161)

{希哲16年1月18日8歩 K#F85E/E74C-91F1}

進捗時限記録中略

埋め込み記法渡括記法)の応付子オプションなどについての検討終了

概ね方針が固まってきた

引数風の応付子

これまで埋め込み記法には,埋め込み方細かく指定するような機能がなく,例えば画像埋め込みでも表示サイズ水平方向寄せ方指定出来なかった。この問題当然当初から認識していたが,どうしてもごちゃごちゃしがちな部分なので,直感的美しい記法練るのに時間がかかった差し当たり欲しいのは画像埋め込み表示サイズ寄せ方指定出来る機能だが,他の埋め込み対象でも使える汎用的な枠組み整えておきたい

そこで,[寄せ方指定スペース]+([応付])[埋め込み対象]形式採用することにした。例えば,添付譜類PNG 画像100x100埋め込みたい場合,+(100x100)png書けるようにする。

丸括弧内は,函数引数風にコンマ区切りで,埋め込み対象毎に使える応付子設定する。引数名指定出来るように a=xa:x受け取ってもいいが,柔軟性必要なのであえて必須にはしない。スペースを含む文字列扱いたい場合考えられなくはないのでとりあえずコンマ区切りにしておくが,各引数扱い駒手欄感覚近い

他のとして,+100x100 png+100x100,png のように全てを引数的に扱うことも考えたが,あくまでも埋め込み対象とする応付役割まとまり一番分かりやすいという点で丸括弧採用する。また,埋め込み対象URL など長い文字列になることも多いため,応付+直後置く。あるいは,末尾に置く書き分けられるようにする。

水平方向寄せ方

水平方向寄せ方は,表組み記法採用予定スペースを使う方法応用することにした。以下のように,+ 前のスペース無しは無指定4つ未満は左寄せ4つ以上で中央寄せ6つ以上で右寄せとする予定

読み込み中...
{便利}

{}