{日本語表現}{換配確認機能}{確認ボタン}{プレビュー機能}{開閉状態}{応用の可能性}{確認用}{ページ読み込み時}{輪郭選り手抜控機能整備}{Chrome 59}...=}(109)

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

新生デライトの要件

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

舞覧手定め環境整備

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=}
{自動投稿}{ActivityPub 捌き}{Twitter 連携}{Delitebot}{輪郭選り手}{輪郭選り手整備}{希哲15年7月25日}{立求}{検討}{用影}...=}(20)

{希哲15年7月25日の開発 K#F85E/A-E74C-131D}

輪郭選り手周りの作業は「輪郭選り手整備」としてまとめることにした。


デライトの ActivityPub 対応について,必ずしも ActivityPub 捌き にすることにこだわらず,Twitter 連携も含めた「自動連携ツイスト」として実装することを検討し始めた。この場合,任意アカウントを指定して自動投稿するような形になる。


デライトから立求する場合の用影として Delitebot検討

{大きな付徴}{許容範囲}{追加検討}{検討開始}{暗証語再発行機能}{公開範囲設定機能の試験的導入}{希哲15年7月24日}{新生デライトの要件}{大きな問題}{デライト高速化}...=}(46)

{希哲15年7月24日の開発 K#F85E/A-E74C-75D9}

新生デライトの要件追加検討

公開範囲設定機能の試験的導入

公開範囲設定機能の試験的導入検討開始

本来,デライト収益目標達成後付徴としていたが,デライト開発がとっくにその水準を越えていることもあり,新生デライト盛り込むことが考えられるようになってきた。

描出公開原則維持したまま,利用規約免責事項明確にしておけば大きな問題はないだろう。

暗証語再発行機能検討

公開範囲設定機能と同時に,メールアドレス利用した一般的な暗証語再発行機能導入視野に入ってきた。

メールアドレスを保存せずに再発行出来る仕組みを模索していたが,やはり単純性安全性両立させるのが難しい

公開範囲設定機能実現出来るならメールアドレス保存くらいは許容範囲だろう。

暗証語忘れ対策は大きなデライトの課題だったが,ようやく解決糸口が掴めそうだ。

デライトの ActivityPub 対応

残る大きな付徴として,デライトの ActivityPub 対応についても検討

こちらはほとんど費用対効果問題であるため,最後に回し,その時点での高速化保守性次第で決めることにした。

{希哲15年8月1日}{希哲15年7月30日}{理想的な生活律動}{新生デライト開発}{新生デライトの要件}{まとめた}{一日一文}{希哲15年8月}{過ごし方}{輪郭整備}...=}(41)

{希哲15年7月30日の日記 K#F85E/A-E74C-5598}

生活律動矯正着実に進み,快調だった。

今月開発にはここで一区切り付け,まとめ集中することにした。


来月過ごし方についても考えた

理想的な生活律動維持したいが,これまでにまとめた新生デライトの要件8月中に満たそうと考えると,執務時間は全て新生デライト開発に使いたい。輪郭整備一日一文新生デライト宣言が出来るまで休むことにした。よほどゆとりがあるか,気分転換程度にならやってもいい。

その代わりというわけではないが,1日定休通りに休むことにした。

今週執務自体は抑制的だったので休まなくても大丈夫かとも思ったが,生活律動激動脳爆発脳過熱,さらに来月激務まで考えると,ゆっくり呼吸を整える日も必要だろう。

31日加筆修正

=}
{開発}
{}