この記事を作った動機
一応ここには現時点で考えている発想について適当にまとめているだけである。新しくわかったこととか調査結果をもとに、後からまとめなおする必要がある。
ポイント
-
サーバクライアントモデル
- UI 処理をするクライアント(クライアント側)
- OS依存のAPIや実装のためのバックエンド(クライアント側)
- データ関連のバックエンド(サーバー側)
- P2P
-
オープンなデータ構造
- JSON や XML などをサポートしたい
- human readable な仕様にしたい
- 大きなバイナリデータとかはどうするかが課題 それについては、Unityみたいに各ファイルにメタ情報付きでディレクトリ構造を形成して管理してみてもいいかもしれない。
-
拡張可能
テキストや画像、インクオブジェクトだけでなく、独自のバイナリ構造を持つファイルや、独自のガジェットやオブジェクト的なものも扱えるように、機能を追加できる仕様にしたい。 -
バージョン管理にgitを使う?
基本的なアーキテクチャ
x11みたいなサーバークライアントモデルな構造にしたい。
フロントエンド
chromeやfirefoxなどのブラウザ、Electornなどを使う。vite,react,typescriptとかだと比較的モダンに仕上がると思う。
バックエンド
適当にpythonとかphpでもいいので、データ処理とOS固有のAPIの抽象化と呼び出しを担う
基本的なデータ構造
ノート構造
- Notebooks
- Section
- Pages1
- Pages2 …
- Section
ページ構造
基本的には、汎用の位置情報などを保持するオブジェクトが定義され、それを継承することで、テキストや画像、動画、PDF、インク、3D view(include pmx and blender ext files -> three.js) バイナリデータなどをそれぞれ専用のクラスを用意し、扱う。
基本的なUI機能や入力など
- ファイルのドラックアンドドロップ
- 貼り付け、コピー
- InkAPI
- マウス、キーボード、タッチ
- 複数ウィンドウ
- 長時間の処理時間がかかるものは進捗表示と非同期処理
-> ユーザーに不快感を与えない、心配させない UI/UX
機能の在り方について
いろいろ気になる機能があるが、詰め込め過ぎても仕方ないという印象。人はいろいろ選択肢があると、選べなくなるということを考慮すると、ある程度制約のある仕組みや、あえて実装しない機能を決めたり、使い方を制限するところも必要であると考えられる。
労力的な問題について
正直 OneNote の代替を一から作るみたいなのより、Obsidian のプラグインを不満点を反映してガンガン作っていったほうがいいんじゃないか説ある。
Obsidian は少なくとも、プログラム本体自体のソースコードなどは公開されていない、closed source なようなので、アーキテクチャ的にも新しく作ったほうが都合がいいかもしれないということになり、現在作業中(2025/9/8)
参考にしたサイトとか
ここについては今のところ特になし。