TODO
自分宛のメッセージ
- TODOは「実行可能なこと」を書くもの。
- 凡例
- \*+\d+: 優先すべきタスク。優先度は星の数、\d+は一意な数値
- d\d+: タスク\d+に依存している。タスク\d+を優先して片付けるべき。
- s: 何らかの理由で延期中。(おそらくdなのに依存しているタスクがTODOに書かれていない、がやらないことに決めているタスクを詳細に記述することに時間を割く必要性はない。sは「今はこれに時間を割く必要がない」という意味)
- 忘れずにいるべきこと
- CommonGatewayクラスはXML-RPCやJythonなどから叩くことの出来る共通のインターフェイス
- MediatorクラスはJythonやJavaなどの直接POJOを扱えるものから、よりダイレクトに(Javaの型の情報などを利用して)操作するためのインターフェイス
- ユーティリティ的なメソッドはユーティリティクラスにまとめるべき
- InvocationTargetExceptionはgetCauseする。XML-RPCで何か失敗して例外が起きたときに、例外を見て何が起きたか推測できるように、なるべく情報を出すべき。
- XML-RPCのライブラリがリフレクションで引数がHashtableのメソッドを探すので、CommonGatewayの引数の型がHashtableのところをObjectに変えるとXML-RPCが動かなくなる。
- FLASHを作るときはnon-stopバージョンとstep-by-stepバージョンの両方を作る。non-stopはぼんやりどんなことが出来るのかを眺められるように、step-by-stepは試しながら1歩1歩進めるように。
- あちこちに書き散らすと後で大変なので、新しく思いついたアイデアは必ずここのinboxに書く。
TODO
INBOX: 未整理のタスク
- レンダリングエンジンを切り替え可能にする
- CommonGatewayからそれを変更できるようにする
- init.pyでそれを設定
- Zオーダーのあるレンダリングエンジン(デフォルトEdge:0 Vertex:1)
- makeDictとsetZOrder, getZOrderをつける
- http://www.genpaku.org/other/eclipse/plugin_architecturej/plugin_architecture.html 読む
- http://pyunit.sourceforge.net/pyunit_ja.html 読む
- json.simpleのライセンスを調査。使い続けるかやめるか検討する。
- ローカルのGRINEditで保存した物をFTPでサーバにアップロードしたら、ウェブページ上のアプレットでも同じ物が見える
- http://wiki.python.org/jython/ReadlineSetup
- 現在のgetParamsは値がデフォルトかどうかにかかわらず全部の値を返しているので、それを保存や通信に使うと量が多い。
- デフォルトと異なる量だけを返すgetParamsSimpleをつける?
- JSONを圧縮した状態でも読み書きできるようにする?
- 出力されたJSONを人間に読み書きしやすい形に変えるPythonスクリプト
- positionとかを削除するオプション?
- drag & drop されたファイルの拡張子がpyの時はスクリプトとして実行する?
- XML-RPCでのaddやdel、modのクエリーを即座に実行しようとするとレンダリングや描画のスレッドがロックしているので応答性が悪くなる。
- 変更を伴うクエリーをためておくスレッドを1つ作る。このスレッドはwaitし、レンダリングの終了時点でnotifyされる。
- PythonのxmlrpclibでGRINEditから文字列を取得するとUnicodeで返ってくるのに、GRINEditにUnicode文字列を投げると化けてSJISならOK。xmlrpclibが余計なことをしているのかな??投げるときに....encode("sjis")とやればいいだけではあるけど。
- Jythonコンソールで日本語を打つこと自体は出来るけど、頂点のラベルに日本語を指定すると化けるのも同じ現象か?
- 調べる
- 名前空間をフラットにする必要はないが、全部のオブジェクトが入っている名前空間があるべき。
- grinedit.addObject("Vertex", "vertex1")みたいに名前で参照して追加できるように。
- 現在は選択された頂点はSelectionというレガシーなものに入っているけど、これをVertexやEdgeやLaw同様にHashtableに入れてXML-RPCからアクセスできるようにすべき。
- 今はJavaとJythonからしかアクセスできない。
- この両方をやったら grinedit.addObject("SelectedVertex", "vertex1")みたいな方法でXML-RPCから頂点の選択が出来る。
- grinedit.newTable("Hoge")してgrinedit.addObjects("Hoge", ["v1", "v2", "v3", ... ])する?
- グラフをシリアライズして復元したときに、内部でオブジェクトの管理のために振られている一意なnameフィールドの値が変化する。これでいいのだろうか?将来的に何か問題を起こしそうな気はするけど、逆にこれでいいのかも知れないという気もする。一意でないと行けないnameフィールドを元通りに復元するなら、グラフのマージとかはできないわけで、元通りに復元しないことを前提として頂点のnameがどう変わったかの対応付けをするようにしたほうが結果的に色々いいかもしれない。
- 入れ子頂点
- 入れ子頂点は親と子の位置がかっちり固定されているよりも、子供の頂点が動けるほうがいい。まるくて、中にはいるべき頂点の重心が自分の中心であり、最も遠い頂点までの距離*1.1くらいが半径であり、中に入るべき頂点には中心からの距離に比例した引力を持ち、中にはいるべきでない頂点には半径*1.1以内に入らない制約。つつむ頂点の中に入っている普通の頂点は引力で緩やかに拘束されつつ外の頂点との辺による引力で位置を変えたりする。いくつかの頂点が複数の親に属しているとベン図みたいになりそう。これはそういう構造にするためのUIがちょっと難しそう。
- 中に入らない制約の反作用を親の頂点が受けるべきか。たぶん基本的に全ての力は反作用を持つべき。でももし持たないならドラッグドロップが簡単にできるかも。
- 頂点は物理演算になれないが、でも描画したい物理演算もある。頂点と呼んでいた物は実は「インターフェイスIRenderableを実装したクラス」であるべきなのではないか。辺もIRenderable。でも辺の接続する頂点として辺を指定されるとイヤ…でもないのか…うーん。追加できないのがイヤという可能性もある。
- グラフの要約機能や動的に開いたり閉じたりは需要がある。
- たかだか300頂点で15FPSまで落ちてしまうことがある。長い紐状のグラフがぐるぐる巻きの状態になってしまったときに、外側の頂点の拡散を辺の引っ張る力が邪魔をするために、頂点が密集した負荷の高い状態が持続してしまう現象。
- デフォルトの物理演算は、イヤならはがせるわけだから、機能てんこ盛り路線でいいのかも。それなら「反発力がなかなか減らないときには拡散を加速する」という物理法則を入れる手がある。
- setter/getter生成スクリプト
- PythonをインストールしなくてもいいようにJythonで動かす?
- Developer向けプラグイン?
- PythonをインストールしなくてもいいようにJythonで動かす?
- ActionScript?
- GRINEdit よくある失敗 をFAQに変える
- 西尾泰和のブログ: オフラインミーティングのログ
- 西尾泰和のブログ: log入れ子頂点の考察
- ニーズ:FreeMindみたいにInsやEnterで頂点追加するため
- キーイベントのリスナをプラグインから登録
- リスナはフラット?
- もし衝突が起こったら?
- 特定の条件の時だけアクティブなリスナ
- リスナ自体は常にアクティブで、特定の条件ではないときにはイベントをドロップするほうが適切な設計かも知れない
- 辺や頂点を作成するときのためのテンプレート?
- チュートリアルがあればテンプレートはいらない?
- ツリーを見栄えよく表示するための初期配置
- ツリーの兄弟の順序を保つための制約
- ツリーの兄弟の深さを保つための制約
- 「それGRINEditで(ry」
- sodaplayをGRINEditで
- 位相と振幅をパラメータに持つ「周期的に自然長を変える辺」
- 自然長タイプのバネの力(既存)
- 壁制約(既存)
- 壁に当たったときに振動を逆方向にするもの
- sodaconstructorをGRINEditで
- 編集モードと実行モード(物理演算セットの切り替え)
- pauseしてdelLaw、addLawで一応出来る
- クリック、ドラッグで頂点や辺を作成するMouseOperation
- 辺の選択
- サイドパネル
- サイドパネルの操作で選択されている辺のパラメータを変更
- 編集モードと実行モード(物理演算セットの切り替え)
- 音声認識でタグクラウド
- リンクは少なめに張った方がいい。
- しゃべった後、散らばった頂点を眺めてリンクを張る。発散と収束のプロセス。
- NarVisualizer
- Listlike、DictLikeの頂点
- 親頂点から子頂点への矢印の接続点が、中心を指さないことがちょっと違う。
- 「複数の頂点が貼り付いている」という実装では矢印が箱の間の壁を指したりして都合が悪そう。やはり「接続位置が指定されている頂点」という実装が正しそう。
- 根からたどれなくなった&画面外に出た頂点の消去
- Listlike、DictLikeの頂点
- TouchGraph
- sodaplayをGRINEditで
- プラグインからSWTのGUIを出す際にswt.jarやswt.dllがどういう扱いになるか?
- デフォルトのGUI自体をプラグインにしてしまえば、追加のGUIとswt.jar、swt.dllの関係を悩む必要はなくなる
- 操作マニュアルの自動生成
- MouseOperationインスタンスはメニューに表示する文字列を持っている
- メタキーによる修飾をサポートしたので機能がメニューに書ききれない
- 機能説明の文字列も持たせる
- メタキーによる修飾をサポートしたので機能がメニューに書ききれない
- MouseOperationインスタンスはメニューに表示する文字列を持っている
- 頂点の中の文字列も動的に書き換えたい
- グラフをネットワーク越しに共有して複数人で同時に編集できるようにしたい
- サーバで物理演算をやって、クライアントはその結果を受け取って表示するだけにするか。
- JythonやXML-RPCではない操作も全部CommonGatewayを通すことにして、そこでサーバと通信する?
- 全部まとまっていて楽そうだけど、パフォーマンスはうなるだろうか?
- plugin関連
- 「無視するプラグイン」ファイルをpluginsフォルダに?
- 能動的プラグインのロード
- 「あるプラグインがすでにロードされている必要性のあるプラグイン」ってあり得るかな?問題になりうるかな?
- 最悪Pythonスクリプトで「起動に必要な条件が整っていなければ自分自身をwaitsetに入れる」とやって、プラグインのロードが完了するたびにnotifyAllすればいい。
- 全部終了しても起動条件が満たされないプラグインがあったらユーザに知らせるべき。
- 実際問題として実行時にPluginsフォルダ内のPythonスクリプトが呼ばれるだけ。
- 呼ばれるのはinit.pyだけ
- こうしておけば他のスクリプトを呼び出す順序はプラグイン作者の管理下に置かれる。
- サブディレクトリ内にもinit.pyがある場合、常に親が先に呼ばれる
- それが自然だと思う。共通して使われるリソースを先にどうこうしておくとか。
- グローバル名前空間を汚染しないように、グローバル名前空間を引き継いだexecは使わない。空の名前空間を使うか、importを使う。
- 実はうまく配置を考えると、Jythonライブラリとしても働くかも。Jarが全くないプラグイン
- それならpluginsって名前じゃなくてdependencyのがいいかも。現状でswt.jarなどが入っているフォルダがそれ。
- 呼ばれるのはinit.pyだけ
- GRINEditにコマンドライン引数でPythonスクリプトを渡した場合に、それを実行
- 全てのプラグインの初期化が住んだタイミングで?
- 一番最初に?
- 一番最初に実行されて「初期化が済んだら実行するリスト」に初期化が済んでから実行して欲しいものを入れればよい。
- 一番最初に実行されて、いらないプラグインを無視リストを書き換える。
- あ、それだと無視リストを設定するスクリプトが走った後に呼び出される必要があるのか。
- わかった、最初に実行されるスクリプトの代わりに走るんだ。指定されなかったらdependency/init.pyが走る、と。
- これのメリット:GRINEdit test.pyでテストが起動され、 GRINEdit narVisualizer.pyでNarVisualizerモードで起動し、何も指定しなければプレーンなGRINEditが起動する、なんてことができる。
- タブレットでスケッチっぽく頂点や辺の追加がしたい。
- Java 2D による半透明描画で半透明頂点。
- いまはグラフのインスタンスが1アプリに1個だけど、複数個になる可能性を考えるべき?必要になったときでいい?
- 本体を起動する実行可能Jar
- スプラッシュウィンドウを出して、出力された情報をそこに出す。
- 本体画面が表示された後で、"HIDE_SPLASH"とか出力して、ランチャー側はその文字列を見たら隠れる。
- エラーが起きた場合にはそのメッセージを出せばいい。
- LibreSource - JyConsole
- applyのパターンをパラメトライズ
- Jython Course Outline
- Jython Consoleのデモ
- vs = med.getVertexList()してからvs[0]した場合の挙動がどうなのか確認
- v = med.getVertexDict()["Vertex0"]できた。これを使ったデモ。
- edgeのデフォルト時の値が-1なのはバッドノウハウ。getParamsして見せたときにかっこわるい。
- med.getMarginalEdges色をつけてからlengthを伸ばす
- XML-RPCのデモはPL_Wallを外した後つり上げてPL_Cohesionでいきなり貼り付かないようにする。その後ぶら下げて貼り付ける。
- 物理演算クラスはレンダリングエンジンクラスが持つべき?
- 「何に使えるの?」という質問にはウェブサイトのグラフによる可視化をやって見せて「これがたったの~行で書ける」というのがいいのだろうか。
- 利用できる頂点・辺・物理演算の一覧が得られれば、それ全部を追加するテストも簡単だが…。