Kozaneba開発日記2023-01-25

「Kozaneba開発日記」というタイトルは久しぶり

前は〜とリンク貼ろうとしたが、個別の1日ではなく6〜7月の活動をまとめたページを作る方が良さそうなのであとで

最近の活動まとめ

線を引くUI

Kozanebaを考える花火に使っていて、現状の線を引く機能が不満
- 「グループに入れる以外の方法で3個以上のものの関係を記述することができる必要がある」という理由で今の実装になっている
- しかし「大部分のユースケースでは2個の関係でよい」ので、ここにフォーカスしてもっと手軽に使えるようにしたい

何をする必要がある？

こざねやグループをクリックした時に「線を引く」メニューを出す
それをドラッグorクリックで「一時的に線を引くモード」に入る
別の要素でのアップで線を引くそんなことができるか？
メニューのクリックでモードに入れるか？
現在のモードはどこで管理されているか？
メニューで「線を引くモードをスタート」した場合、その後のマウスイベントが通常の処理をされないようにしなければならない
途中での線のプレビューを出すのにはまた別の問題がある

実装上の話

マウスイベントの扱いが、暗黙のモードによって変わる
このモードは何によって表現されてるかというとこれ ts

type TDragTarget = "" | "selection" | TItemId;
type TMouseState = "" | "selecting" | "middle_dragging";

というわけで、TMouseStateに「線を引くモード」を追加する
- こざねやグループをクリックした時のコンテキストメニューに入るメニューを追加
- このモードである時の各種イベントハンドラでの処理を追加
  - こざねやグループの上でのupで「線を作成してモードから抜ける」
  - キャンバスの上でのupで「線を引くのを中断」(線を作成せずにモードから抜ける)

描画中のプレビュー表示を無視すれば「手軽に要素間に線を引く機能」自体はすぐつけられそう

明日一日くらい、という意味

描画中のプレビュー表示

これはあった方が良いが2つの理由で厄介
- 現状の「線」は「複数の要素を繋ぐもの」として定義されている
  - 「書きかけの線」は要素に繋がってないので、マウスポインターに追従する仮想の要素を作るか、線の定義を変えるか
- マウスムーブで更新される値なのでReact Stateを更新するとパフォーマンス問題が心配

既存の線とは別に「書きかけの線のプレビュー」という存在を作るか

0〜1個存在するもの
端点として要素も座標も取りうるようにする
- Q: なぜ単純に座標ではいけないのか？
  - A: 要素にはサイズがあって、線は中心から引かれるのではないからですね
これを他の「線全体」とは別のコンポーネントにしておけば、全体の再描画が走らないからパフォーマンス問題は深刻ではない

これができたら次にやること

線の削除が微妙である問題
線が「距離によって薄くなる」なのをオプションでオフにできるようにする
考える花火をやる上でよく使う機能へのアクセスを短くする
- 例えば「線を引いてこざねを追加」は1メニューでよい
- シチュエーション的にキーボードがある可能性が高いからメニューにホットキーをつけても良さそう
- ホットキーでこざね追加ダイアログ

優先度の低いアイデア

「自動フォントサイズ調整、自動折り返し」をオフにする機能
- 場のデフォルトを変更
- こざね単位での変更
- why？
  - グループタイトルがどうあるといいのか問題の模索として、そもそもグループタイトル的な折り返さない横長のこざねがあると試行錯誤ができるのではないか
  - ソースコードの要素の分析をしようとした時、識別子が折り返されるのはしっくりこない
    - グローバルなものほど長い名前になりがちな特製が自然言語と逆転してる
    - 自然言語ではあちこちで使うものほど短くなる
  - 要素の間の関係を線で表現して、動かしながら思考を整理するのとか、ソースコードの構造の言語化に向いてると思うんだよなー

2023-01-26

こざねにそもそもupのハンドラが付いてないぞ

こざねはグループと違ってドラッグドロップを受け取らないからだな
downで処理して良いか？
- 違うな、これはドラッグの開始か。
キャンバスとグループがupを受け取ってクリックかどうかの判定をしてるのだな

線を描き始める時に対象を記録しておかなければならない

できた

「描きかけの線を表示する機能」をつけようかと思ってたけど、先に矢印なのか線なのか指定できるようにしたくなった

EnterキーでAddKozane Dialogを開く

メニューにホットキーをつけるのは厄介だな
メニューが表示されてるかどうかで切り替わる必要がある

画像用意

線矢印対立イコール

できた

プレビュー機能、本当に必要か？

そんなものより線を消す方法の改善が必要では？
今「leave from lines」というイマイチ意味の分かりにくいメニューを押すと、そのこざねがすべての線から離脱する
- =二項関係しかないなら、すべての「つながってる線を消す」に相当する
今回作ったこのUIで消すのはどうか
- 二要素を指定できるので「その二要素の間の線を消す」する
できた

next action thinking

今の瞬間「クリックしてAキーでそこから線を引いたこざねを作成して編集モードに入る」とか考えてるけど、本当にそれでいいのか少し冷静になって考える

メニューにホットキーをつけるのは別の話

その機能を頻繁に使うようになるかどうかは未知数だし。
実験的機能としてメニューにつけて、しばらく使ってみてから考えるべき
- いやいやこれサクッと追加しようと思ったけど全然簡単ではないか
- ユーザが非同期に行った「こざねの追加」の後でその追加されたものを対象とした処理が必要だがそんなところにフックポイントなどない
  - あると将来の拡張にも有益そうな気がするが…
- この機能を使った場合
  - クリック、メニューをクリック、テキストを入力、好きな場所に移動
- 使わない場合
  - エンター、テキストを入力、クリック、メニューをクリック、クリック、好きな場所に移動
- いうほど手間は減ってない

それよりもフォント自動調整をしないレンダリング方法を追加することの方が重要

これはデータ保存の形も変わるから大きいタスク
一旦保存はされない実験機能として実装したら良さそう

線の半透明をオフにする機能は単なる見た目のオプションなので実験的機能としてつけよう、これは楽

UIいらんなと思った
✅フィーチャートグルを露出した

Cypressのテスト環境も作り直さなきゃいけないんだった

next action:

Cypressのテスト環境
フォント自動調整をしないレンダリング方法の実験

2023-01-27

from Kozaneba開発日記2021-08-03

Cypress環境でGoogleが「このブラウザは安全ではないのでログインさせませーん」と言ってくることがわかった
Firebase Local Emulatorを使う

https://firebase.google.com/docs/emulator-suite/install_and_configure?hl=ja

https://firebase.google.com/docs/cli?hl=ja
- $ npm install -g firebase-tools
- $ firebase login
$ firebase init emulators
$ firebase emulators:start --import firebase_emulator_data
- Error: Process java -version has exited with code 1. Please make sure Java is installed and on your system PATH.
- Error: firebase-tools no longer supports Java version before 11. Please upgrade to Java version 11 or above to continue using the emulators. できた

表示の変更、API経由で定数を書き換えるだけでテストしようと思ったが、そもそも定数を元に定数のスタイルを作る形になってるから後からAPIで定数を書き換えても意味がないな

スタイルが毎回定数を参照しにいくようにするとそれはそれでパフォーマンスの問題になりそう
TKozaneItemのcustomにno_fontsize_adjustmentをつける案
- DOMを丸ごと切り替える

🪴 Quartz 4.0

Kozaneba開発日記2023-01-25

Graph View

Backlinks