{希哲17年1月28日の開発}{希哲17年1月28日の進捗}{希哲17年1月28日}{こうして}{追加せず}{余力が無い}{著作権上}{濫用される}{対応済み}{「複写失敗:描写が空ではありません」}...=}(158)

{希哲17年1月28日21歩 K#F85E/E74C-46A3}

進捗時限記録中略

また新生デライトの要件ではあるが,ついさっき急に実装イメージまとまってしまった輪郭複製機能実装終了出振るい手定め済み

描写欄状態新規描出フォームで,自輪郭輪符知名欄貼り付けるドロップすると輪符から知名描写複写される

複写成功する「複写完了」表示「複写失敗:自分の輪郭ではありません」「複写失敗:描写が空ではありません」違了表示付け自我知番の省略にも対応済み使い勝手非常に良好

これまで通り輪郭複製機能」と呼ぶべきかどうかは再考の余地があるが,眠気考える余力が無いのでとりあえずは仮称としておく。「輪郭複写機能」の方がしっくり来る気もするが,「輪郭複製のための機能」という意味ではそこまで間違っていない


輪郭複製機能については,昨年5月18日の開発で「知名描写複製して新規描出フォーム移動するボタン」として実装することを考えたが,その後用合い改良経て抵抗感募っていた

輪郭直接複製するような機能やはり避けたい手軽し過ぎる誤操作濫用可能性高まる適切な手間というで,新規描出フォームへの複写というアイデア悪くなかった。ただ,現状の輪郭選り手理想的にまとまっているので,極力ボタンのような要素追加したくない思うようになった

さっきふと,「知名欄への輪符貼り付け」というについて考えていたら,これが急速にまとまってしまった過去にも何度か脳裏をよぎっただが,その時いまいち気乗りしなかった

貼り付け方式最初の懸念誤入力だった。復元ボタンだけでは心許ないので,知名であることを条件にしようとしたが,空の知名書き始めることは少なくないので中途半端だ。複製したい輪郭検索してから写し取り貼り付けという流れ考えると,知名欄いちいち空にしなければならないのは煩雑過ぎる

間もなく描写欄という条件なら全く問題ないことに気付いた誤操作懸念なくなったので,ドラッグ&ドロップにも対応することにした。

もう一つ自輪郭のみという制限付けることにした。描写内自我知番の省略Aejs対応するのが難しいという問題もあるが,濫用され著作権上手溢れ増えることが予想される他人の描写扱い慎重に,という意味でもこれくらい適切だろう。

こうしてするする実装イメージまとまり一通りの機能付けた実装難なく完了した余計な視覚要素追加せず,それでいて直感的という,理想的な輪郭複製機能あっという間に出来てしまった

=}
{希哲17年1月28日の開発}{希哲17年1月28日の進捗}{希哲17年1月27日の開発}{希哲17年1月28日}{位置固定表示}{応用出来そう}{画面左下}{指定要素}{@msg.shw_cmn()}{くっつけて}...=}(191)

{希哲17年1月28日14歩 K#F85E/E74C-9326}

=}
{希哲17年1月25日の開発}{希哲17年1月25日の進捗}{希哲17年1月25日}{縦方向}{誤タップ}{ページ内移動}{定かではない}{固定表示ボタン}{これなら}{短くない}...=}(109)

{希哲17年1月25日10歩 K#F85E/E74C-7A41}

進捗時限記録中略

吹き描き外背景ダブルクリックダブルタップ新規描出フォーム移動出来るようにして終了出振るい手定め済み

デライト最初期新規描出フォーム固定機能試していた希哲13年8月1日4歩用合いだったが,自分でも驚くほど忘れていた固定機能削除以後何度か再活用検討した記憶はあるが,今ほど全体的な用合い方向性定まっていなかったからか放置していた新規描出フォームへの握接について先日あれだけ検討していたのに全く思い出さなかったついさっきふと思い出した灯台下暗しというやつか。

初見分かりやすい用合い必要なので全知検索窓固定機能輪結予定通り実装するが,スマートフォン右手持ちではタップしにくい位置だとは思っていた個人機でもマウスカーソル移動距離短くない。しかし,これならよくある固定表示ボタンよりよほど賢い上手い補完手段出来た

面白い発見二つあった。

現状幅狭領当てでは吹き描き外背景小さ過ぎ誤タップしやすいが,これは縦方向吹き描きマージン調整していくことにした。

=}
{希哲17年1月22日の開発}{希哲17年1月22日の進捗}{希哲17年1月22日}{似た形態}{似た機能}{錆びついている}{煩雑過ぎた}{勉強していた}{引装した}{TeXworks}...=}(119)

{希哲17年1月22日7歩 K#F85E/E74C-DD27}

進捗時限記録中略

デラング整備化学記法見直し終了

現時点ではやはり \ce( ... \)\ce[ ... \]最も無難な記法であると結論付けた


昨日直感的にこの記法思いついたが,実際に使ってみると,閉じ括弧前の \忘れやすいという問題気付いた慣れの問題もあるので欠点結論付けるのは早いが,数式記法\( ... \)比べて \ce( ... \)括弧対応関係直感的に認識しにくいというのはありそうだ。

TeX では \ce{ ... }数式模動内側書く必要無いため,いっそのこと,これだけでもいいのではないかと思った

しかし,これだと化学記法というよりは TeX 風記法mhchem使っているように見えてしまうTeX ではバックスラッシュ波括弧多用されるからこれが自然に見えるだけで,デライトでこれがぽつんとあっても違和感が大きい特に波括弧デライトにおいて特別な記号なので,濫用避けたいいずれにせよ行内別行立て書き分け出来ず書き分けせずに文脈挙動変えれば TeX 的でもなくなるので,良い案ではなかった。

似た機能似た形態に」という言語設計原則立ち返ると,やはり化学記法数式記法似ているべきだろう。

では,閉じ括弧前のバックスラッシュ省略可にするかと考えたが,これは実装上の問題大きい入れ子になりうる閉じ記号処理出来なくはない一気に面倒になる。しかも,化学記法でそれをすると数式記法でもしないと整合的ではなくなる。現時点化学記法使い勝手のためにそこまでの実装コスト払う意義見出せない

読み込み中...
=}
{希哲17年1月19日の開発}{希哲17年1月19日の進捗}{希哲17年1月19日}{時間をかけてしまった}{確認出来た}{過去の自分}{置き換えられた}{これほど}{再評価し始めた}{そんなもの}...=}(253)

{希哲17年1月19日14歩 K#F85E/E74C-3191}

進捗時限記録中略

highlight.js版存更新終了

10.6.0 からスクリプト最新版11.7.0 へ,Zenburn装体書最終版10.7.3上げた出振るい手定め済み

希哲15年7月18日10歩更新検討したが,当時対応言語検証必要判断し見送り,以来そのままだった。約2年前版存なので,流石に対応言語云々より弊害の方が大きいだろうと更新決めた

作業自体あっという間に終わる見込んで昨日深夜着手したが,最新版従来の Zenburn事実上消えていたため,カラーテーマ検討時間を取られてしまった散々考えた結果Zenburn最終版利用して現状維持とすることにした。

カラーテーマ検討

最新版Zenburnstyles/zenburn.min.css から styles/base16/zenburn.min.css移動していた上に,従来とはほとんど別物になっていた様子Base16 になったからなのか事情よく分からないが,読みにく過ぎるのでいずれにせよ使い物にならない

気になる部分装体上書きして調整出来なくもないが,そこまでするならデライト独自カラーテーマ作りたくなってくる取り急ぎ代替テーマ探すことにした。highlight.js 導入時それなりに時間をかけ検討した希哲15年3月9日11歩ので,当時の記憶からある程度見当付いた

読み込み中...
=}
{希哲17年1月15日の進捗}{希哲17年1月15日の開発}{二輪鎖}{希哲17年1月15日}{こうなったら}{縮小する}{計算した}{応用出来た}{詰め込める}{余地が無い}...=}(168)

{希哲17年1月15日18歩 K#F85E/E74C-2F5F}

進捗時限記録中略

全知検索窓固定機能吊るし輪郭への輪結新規描出フォームへの輪結加えるアイデアについてまとめ終了

画像素材は,背景用二輪鎖上矢印アイコンといずれも既存のものを使い,自我アイコン左側配置する幅狭領当てでは,入力欄への捕活時隠れ入力欄伸長するようにする開発者通類で作った案


新規描出フォームへの素早い握接長いあいだ課題だったが,これも急に解決してしまった新規描出フォーム固定機能との関連考えることがく,今回先の検討中に考え始めた

右下あたりに輪結固定させるのがよくある方式だが,何度考えてもデザイン的まとまり欠ける何より幅狭領当てでは重なり気になる明らかに邪魔だろう。

新規描出フォーム左上にある+ボタン元々新規描出フォーム固定機能兼ねていたので,これをスクロール追随させて,どこでも新規描出フォーム呼び出せるようにするか……等々これまでとにかくあらゆる検討したが,どのにも何かしら問題があったさっき方針固まった全知検索窓固定機能合わせ下スクロール現れるバーにしても,せっかく占有領域減らす工夫相殺されてしまう。

デライト構造上仕方ないこと,と新規描出フォーム固定機能のように諦めかけたが,こうなったらもう全知検索窓何とか利用するしかないのではないか,と再び考え出したのが良かった

読み込み中...
{希哲17年1月12日の開発}{希哲17年1月12日の進捗}{希哲17年1月12日}{機運が高まっていた}{余計な部品}{理想的なばら成し}{無駄が大きくなる}{少なければ}{多くなれば}{なりそうにない}...=}(79)

{希哲17年1月12日5歩 K#F85E/E74C-C21D}

進捗時限記録中略

譜類添付機能実装課題だった用合いについて実装イメージ急速にまとまったので少し整理して終了

希哲15年3月24日5歩渡括記法利用した添付譜類管理方式考案し,その方向進んできたものの,一点だけ,「埋め込みたくない添付譜類どうするか」という問題浮上し停滞していた

これに関してはひとまず編注記法活用することを思い付き必要なら追い追い記法調整していくことで解決した+[拡張子]-[拡張子] のようにすれば非表示出来るという記法考えたが,埋め込み記法全体整合性考える必要があり,なかなかまとまらなかった

昨年から輪郭選り手添付譜類管理用の部区設ける再検討していたが,やはりどう考えても美しい用合いにはなりそうにないアイコン拡張子並べるとすると,当然添付譜類多くなればごちゃごちゃしてくるし,少なければ無駄が大きくなる何より現状の輪郭選り手理想的なばら成しなので,これ以上余計な部品加えたくない

渡括記法利用した添付譜類管理方式再評価機運が高まっていたところで今日の思い付き決め手となった。

{考えた}

{}