forked from CueMol/cuemol2
-
Notifications
You must be signed in to change notification settings - Fork 0
/
memo.txt
executable file
·3684 lines (2840 loc) · 172 KB
/
memo.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
2008年11月22日
○スクリプト呼び出しのインタフェイス
名前ベースのみにする←内部スクリプトJS, QSなどからの制御
タイプライブラリ形式は中止する。
⇒外部JS(XPCOM)からの呼び出し自由度は必須ではない。
自由度を犠牲にして実装の簡便性を優先する。
＊内部スクリプトのインタフェイスは計画通り
＊外部スクリプトはGUI構築のためのみに使用される。
＊外部スクリプトのインタフェイスは必要最低限の非拡張性のものに変更する。
外部スクリプトに提供するサービス
・XPCOM Wrapper object(xpcw)の機能
xpcwがCueMol Wraper object (qmw, XXX_wrapper)への参照を保持する
(javascriptのwrapperがqmwへの参照を保持するのと同)
メソッド名を文字列で指定して、そのobjectのメソッドを呼び出す機能(invoke)
プロパティーにアクセスする機能(getProp,setProp,hasProp,enumProps,enumPropTypes)
e.g.ファイルを開く
Reader factory objectを得る(in wrapper)
⇒Reader object xを得る(in wrapper)
xに進捗callbackを指定(イベントマネージャ参照)
xにデータソースを指定(local file/stream manager参照)
xにできるオブジェクト名/IDを指定（名前or数値ID）
xに他のオプションを指定(連想配列/JSON)
実行の指令
e.g. 分子レンダラの右クリックメニュー処理
Mol objectを得る（サービスより）
イベントマネージャを経由して、callbackを指定。
クリック時、callbackが呼ばれる（必要データが連想配列に入って渡される）
ポップアップメニューを作成・表示
メニューの実行（xpcw経由）
要検討：npruntime由来のthreadから直接XPCOM側を実行してmenuを表示したりしても大丈夫なのか。ケースによってはthread marshalingが必要だろう。
・効率的な配列と連想配列のアクセス
→配列/hash getはJSONで実装できる（範囲に限定する）、特別な配列/hashは実装しない
・Service(singleton)を呼び出すサービス
メソッド名・引数を指定→呼び出し
返却値の処理
・イベントマネージャ
XPCOMオブジェクトへの参照を保持し、指定されたメソッドをcallbackできるように。
callbackは、イベント発生側のthreadにより直接呼び出されるケースがもっとも単純
Eventをlistenしているthreadが別にあって、そのthreadがcallbackを実行する、
という実装も必要かもしれない。（XUL側がmultithreadだと必要になってくる？)
→ 1.9.1系から？cycle collectorに対応していないせいでassertionに失敗する
↑cycle collectorは関係なかった。LScrCallback objとScript Listener objが正しくreleaseされて
おらず、qICallback::Release()が呼ばれていなかったせいで、最後のGCの段階でも
qICallback（ひいては全JS object）への参照が残ったままになっていた。
qICallback::Release()を正しく呼ばれるようにすれば解決した。
ついでにXPCCueMolのdtorも正しく呼ばれるようになった。（2009/8/11）
・ストリームマネージャ
CueMol側からgecko,XPCOMを隠蔽しつつ、
httpなどのURIをhandlingするために必要。
CueMol側からは単なるLStream派生オブジェクトとしてアクセス可能な
network socketなどを提供できるようにする。
(data pull型interfaceに固執するとThreadが必要になってくるかもしれない)
data push型interfaceも考慮して、Reader/Writer側を実装しなおしたほうが
簡単かもしれない。
----------
2008/11/25
・アプリの構成 --- XPCOM版
xpcqm.dll (or xpccuemol.dll)
cuemol application (qICueMol/XPCCueMol) の起動init()→すべての初期化initialization
cuemol application (qICueMol/XPCCueMol) の終了fini()→すべての終了化finalization
その他のサービス
Singletonを呼び出すサービス, getScene(), getObject()など
1. XPCCueMol::init()は必ずはじめに呼ばれる(external JSから)。
2. XUL等による、View用のplugin配置(複数・途中可)
3. pluginをMolView等にattachする(external JSから)
・XPCOMラッパ
XPCOMに対するObjWrapperでの値やりとりは基本的に
nsIVariant
経由で行わなければならない。
nsIVariantはfrozen interfaceでないらしいが、使わざるを得ない。
invokeの引数渡しにはarrayを使用したいところだが、
XPCOMのarrayは複雑（配列全体での型が決まっており、値のホモ・ヘテロにより処理を分岐させなければならない）
→invoke0, invoke2など引数の数によりメソッドを作ってある程度は対応可能（この方が処理も速いだろう）
・シーン記述のXMLについて
アトリビュートにXMLが埋め込めないので（あたりまえか）
アトリビュートには、マネージャなどで定義したIDの参照を指定する。
マネージャなどで定義しない場合は、アトリビュートでなく子エレメントの形で定義する(XMLで記述できる)
よく使う記述については、独自の記述を定義する(色、分子選択など) → Parserを作る必要性
色: rgb(n,n,n), rgba(n,n,n,n), #NNNNNN (HTMLの記法), hsb(n,n,n), hsba(n,n,n,n); nは実数, Nは16進数
分子: A.100:200.CA, name ASN and !elem H 等 (バージョン1.1と同じ)
<prop name="carbon_color">
<object type="color">
<prop name="ambient" value="#NNNNNN"/>
<prop name="specular" value="#NNNNNN"/>
<prop name="diffuse" value="#NNNNNN"/>
<prop name="povray"/>
<!-- CDATA/definition used in povray rendering -->
</prop>
</object>
</prop>
例えば、povray用の項目については、CDATAで定義した文字列が直接渡されるようにする。
（どこにどのように渡されるかは、今後の課題）
色には
・solid色
・gradient色
が考えられる。
----------
2008/11/26
mcwrapgen3に問題点
★1/8での問題点を考えると，以下の事項は間違っているかも（wrapperがinstance化すると勘違いしていた）
Objectの方でSmartPtr型だと宣言→WrapperはSmartPtrしか扱えなくなる
プロパティーでImmediate型を使用→ImmediateをwrapしたWrapperがgetterで生成される
そのWrapperを使って操作を行うとWrapperのコード中でInvalidCastが起こる（WrapperはSmartPtrにcastしようとするから）
↓
QIFファイルのプロパティ定義で記述する型は，実際のobject中で定義されている型情報を知らせるものとする．
getterが返す値の型を指定しているわけではない（getterが返す値の型は，そのobject型のQIFファイルで定義したものから変えられない）
プロパティ型とQIF型が異なる場合は，getter/setterで型変換を行うコードを生成するようにする．
実際にはQIF定義がImmediateの場合はあり得ないので、
問題は(Ptr/SPtr)<-->(Immed/Ptr/SPtr)変換のケースのみとなる。
ただし、対角（同等変換）は実装済み。
当面の問題はSPtr<-->Immed変換のみと考え、それのみ実装する。
そのうちPtr<-->Immedも必要になってくるかもしれない。
Ptr<-->SPtr(あるいはその逆)はあまり必要性がなさそう。
----------
2008/12/16
Win32の実装．
UNIX/Xの実装と同レベルまでは完了．
2009/1/6
DisplayList実装
DisplayList, View, Renderer, Object, Sceneのcleanup順序に問題があり，正常に終了できない．
DisplayList: 対応するSceneのViewが全て無くなったら無効
最後のViewがなくなる前・直前に，Sceneはcleanupするようにする．
--> unloading() というのを作って対応
2009/1/8
mcwrapgen3に問題点(←解決済み)
smartptrにしたらプロパティなど，polymorphismを扱えなくなってしまっている．
thisは常に非smartptrにしなければならない．
→typelib/XPCOM用の実装は全て破棄・wrapperはinstance化しない前提で
→pthisは常に通常ポインター型になるようにした．
（qifでのsmartptr宣言が意味がないようになってしまった？）
★引数などについても，
基本的に，qifで指定した型・ポインタタイプに変換するようなコードを生成
１．（＊何でも）→pointer変換
２．（＊何でも）→smartptr変換
を行う．LScriptable::isSmartPtr()で判断してcastするようにする．
２の場合の中で，pointer->smartptr変換が若干問題がある可能性有り．
----------
2009/2/25
Atom, Bond, Resid iterator一応完成（選択対応）
Simple, trace renderers一応完成（coloring対応）
Compatible renderersのenumeration作成（→dialog選択）
----------
2009/3/26
OSX/AGLの実装（一応完成）
ログの実装変更
イベント＋ファイル１つ形式に限定する
→GUIでのログ表示はイベントで捕捉する
★イベントの実装１
一般的なCallback object：LScrCallBackを私用した実装
Script wrapperで必要な実装
・関数オブジェクトからLScrCallBack interfaceを持つcallback object(XXCallBack)を実装する
・wrapperで引数に関数オブジェクトが渡された場合に、XXCallBackに変換するようなコードを実装
・XXCallBack::invoke()を、関数オブジェクトを呼び出すように実装する。
Scriptから使用可能なイベントの実装手順
・イベント発生源の実装（QIF、addListener/removeListenerを含む）
・Script用proxy listenerの実装（LScrCallBack*を保持し、LScrCallBack::invokeを呼び出すだけ）
Scriptイベントの削除（removeListener）を実装する・メモリ管理→IDを返し、後でそれを使ってunregister出来るようにした。
----------
2009/3/31
★イベントの予定
・SceneCreated/Loaded
シーンの生成
SceneDestroyed
シーンの破棄
↑あまり用途無し？
・SceneChanged
シーン中のobjectの変化(object自体の変化は含まない)
- ObjectCreated(Loaded?)
- ObjectDestroyed
* PropertyChanged
scene名の変更など
シーン中のrendererの変化(renderer自体の変化は含まない)
- RendererCreated(Loaded?)
- RendererDestroyed
シーン中のviewの変化(view自体の変化は含まない)
- ViewCreated
- ViewDestroyed
・ObjectChanged
* PropertyChanged(多種多様)
object名の変更など
・RendererChanged
・ViewChanged
・入力デバイス系
InDevEvent
mouseのlow level event
★イベントobject実装
Scriptのことを考えると、event objectはexception objのような派生クラスに応じた分類にしてしまうとscriptからのアクセスが困難になる。（全部のクラスに対応したscriptable objを作らなければならない、面倒）
→IDによる分類、非階層的、monolithicな実装にする。
→scriptでのイベントcallbackは、引数は可変長配列にする（event種類によって異なるように出来るように）
★プロパティーとイベントの問題点
obj.get("prop1").get("prop2").get("prop3").set("prop4", value);
という風に内部objの内部プロパティーを変更してしまうと，objに変更を通知するすべがない（あるいは困難）．
１．案
Object, Renderer等のpropertyに関しては，
obj.get("prop1.prop2.prop3.prop4", value)
というふうに，toplevelでとりまとめてアクセスするようにし，toplevelのget/setで
イベント処理を行うようにする
問題点
javascriptから，obj.prop1.prop2.prop3.prop4 = valueという形式で
アクセスできなくなる．
２．案 ←現在実装
プロパティ自体にどういうobjectの内部にあるかの情報を保持させる
（実装が困難）
----------
2009/4/4
イベントの実装（プロパティ、一部）
上記２。案を実装。（さほど困難ではないかも）
ともかくもwrapperがsetterを完了した後に（dispatch interfaceで）
LPropContainer::nodePropChgImpl(...)を呼び出すように。
（→direct interfaceからはイベントが起こらないが、使わないのでOK）
LPropContainerは、m_rootuid(root prop containerへの参照ID), m_thisname(root prop containerにおける自身のプロパティ名)を保持することにする。
LPropContainer::nodePropChgImplでroot prop containerへの参照更新と
firePropChanged(...)呼び出しを処理。
root prop containerへの参照更新は、新規に設定されたproperty値がLPropContainerであった場合に、自身のm_rootuidとm_thisname等を利用して、そのm_rootuidとm_thisnameを書き換える。
・ 弱い参照のためのUID実装
LUIDObjectインタフェイスを実装するクラスは、ObjectManagerにctorで登録・dtorで削除を行う。
→UIDでobjectを参照できる。dtorが呼ばれて削除されていた場合はNULLが返るので破棄されたpointerを参照してしまう危険がない。
・Scene, Viewのdirty flagの実装。
Renderer/ObjectはSceneに含まれると考える。
----------
2009/4/19
Eventの発生状況によっては非main threadで発生する可能性がある（特にworker thrのはくlog）
EventManagerをつくり，非main threadで発生したeventはpendingにする→main threadのpoolingによりevent発行
（main threadによる遅延delegation機構）
----------
2009/5/2
マウス周りイベントの実装・スクリプト化
Hittest(point)実装
Toolboxのprototypeを実装
windowsのみ，mouse cursorを指定できるように
★ InDevEventスクリプト化可能性の意義
マウスでの操作をxulのレベルで横取り可能になる
ToolのようなGUIをxulレベルで実装するには必要な実装
○【 TO DO 】
★ Renderer/Objectのproperty changeはSceneのdirty flagをたてる。(event handlerで??)
・完了
Selection rendererの実装と選択変化への対応
↑マウスクリックなどによる選択(一応実装09/08/30)
↑10/1/24 選択反映の機構を変更
----------
2009/5/17
・ Serialization/deserialization
Output
DATA --> LDOM --> stream
Input
stream --> LDOM --> DATA
という実装にした．LDOMは中間表現．
propertyと軽量なデータは全てこの機構で読み書きされる．
大きいデータ，Objectのcontentsはdatachunk構造を使って同じstream中に埋め込まれる．
○【 TO DO 】
★ Document baseの扱い．srcがfull pathで無い場合は，scene fileがあるフォルダからの相対になるようにする．
勝手に相対→絶対に変換しないようにする．
・完了（？）
Serialization/deserializationとchunk handlingは分離する．
SceneWriter/Readerとして，Scene特有のchunk handlingを実装する．
Serialization/deserializationはscene以外の例えばメモリでの直列化にも使えるようにする．
↑readFrom2(), writeTo2()のDATA <--> LDOM変換では
chunkは扱っていないので、メモリでの直列化に使えるはず。
・完了（？）
DATA <--> LDOMとLDOM <--> streamを分離すれば，メモリでの直列化で
streamを経由する必要がなくなる．（DATA --> LDOM --> DATA2）
↑実装した
----------
2009/8/4
・UndoManagerの実装
・ firePropChanged()では、各listenerにpropchanged eventをbroadcastする。
renderer, objectは自己propchg eventをctorでlistenするようにする．
child node eventでは，toplevel nodeにもeventが伝搬する．
必要なタイプのeventのみ受け取るためのフィルターが必要か？
（各ハンドラーでif文でチェックすれば同じことは出来るので、
この段階でフィルターするのは単にパフォーマンスの問題だけ。
実際パフォーマンスが改善するかは不明だが）
同様なことは，mouse eventでも必要か？
→当面はともかくも簡単な実装を重視してbroadcastのみにする．（たいしたパフォーマンス問題ではないだろうし）
・Propertyのedit infoの保存は，propchg event handlerで行うことにする．
→必ずsuperclassにイベントを伝搬するように
_super_t::propChanged(event);
コードを書かないと正しくedit infoが記録されない！！
XPCOM間でのunicode変換を正しく実装．
終了時処理を何とか実装．
xpcomに関しては，wrapperを全て監視する．（使用中wrapperの帳簿を維持する）
最後にcuemol2をシャットダウンするときには，
wrapperが参照しているものもどうせ消えてしまうので，
前もって全ての参照をNULLに再設定する
→終了時処理後にxpcomのGC()が起っても，もうcuemol2内部情報を参照していないので
安全にwrapper(のぬけがら)のみを削除できる．
----------
2009/8/9
・完了
text drawingの実装、thebes APIを利用してcross plathomeにする。
win, osxで動作確認。
xulrunnerをmozilla 1.9.1系に移行
解決済み：mozilla 1.9.1系にすると、cycle collector関連のメモリリーク問題が発覚
----------
2009/8/9
Scriptへのcallback関連のメモリ解放を正しく行うように修正。
2009/8/13
valgrindを使用した、メモリリークのデバッグ
●stylesheet関連のための実装計画
・default flagの実装(root objのみ?)
・getDefaultValueの実装(既定値のQIFファイルでの記述)
・serializationの修正
・Eventの実装修正と、Undoの実装修正
●stylesheet関連のための実装計画(2009/11/23実装開始)
・style sheet repositryの実装
・style sheet object自体の実装
・rendererからの参照機構の実装(loadsheet/unloadsheet)
・style sheet自体の変更時のrendererのupdate機構（←これは当分実装しない）
・mcwrapgen3におけるEnum型プロパティの実装が必要（済み）
getTypeNamesではenum型であると返される
getEnumValues(enum型名)で、どういうIDがあり得るのか調べられるように
enum型は、QIF class内に定義するようにする
enumはvariantでは文字列として保持。UIからは文字列で扱う
↑一応実装した(9/8/23)
----------
2009/8/14
matrix, vector等のクラスについて，内部用とスクリプトからアクセスできる外部用を分ける．
2009/8/15
Scriptable関連のクラス階層を変更した。
smartptr wrapperにevent処理の実装がないように、等々
property event発生処理・root object UID維持処理をwrapper codeから分離した
default valueの実装
問題点：
所有するvariantが必要。bOwnedフラグによる処理はやめた方が良い。
TransientVariantとOwnedVariantが必要。
↑基本的にOwnedにするようにした(9/8/23)
----------
2009/8/23
・Enum型の実装
・mcwgenまわりを刷新、directインタフェイスを全削除した
・LVariantの実装を変更。基本的に所有するようにした。
→ケースによってObject, Rendererが直にLVariantに渡されるようなコードが
一部に存在しているため、Object, Rendererのコピーが作られておかしくなる。
特にdeserializationのコードで、生成したobjectがおかしくなる。
○必要なこと
Object, Rendererは今はSimpleCopyだが、これはView同様NoCopyにするべき。
deserializationでObject, Rendererはdefault ctor直接呼び出しで作られるが、
特にrendererはfactory経由で作られるようにした方が良い。
↑8/30, Scene, Objectは対処済み
・重大な問題点（解決）
上記に関連して、compositeなobjectをstringからdeserializeするときに、getpropしたobjに対して
fromString()を呼び出してしまっているが、これをやると、対象がdefault値だった場合に
default objectの値が書き換わってしまうという問題がある。
↑fromStringS()というstring->object static method (ctor相当)を実装し、
createObj()に文字列引数を渡せるバージョンを作成
instance methodのfromString()は廃止する
----------
2009/8/29
・Serialization/DeserializationとLDom2Treeの再実装
LDom2TreeはLDomTreeのrefactoringバージョン
Treeを中間層に置く
object<-->treeにSer/Deserializationし、streamはtreeをXML形式に書き出す実装にした。
wrapperでの、native型とvariant型間の変換を、LWrapperImpl内に移した
特に、文字列variant型→native型変換時に、native objectがターゲットの場合に、
Type::fromStringS()が呼ばれるようになっている。（Colorで#FFFFFF等で値が設定可能になる）
○発覚した問題点・バグ
Sceneを（終了時以外に）削除して、アプリを終了すると、CycleCollectorでassertionに失敗する。
どこかでメモリ管理がおかしくなっている可能性がある。
・解決した問題点・バグ
chain _が認識されない（simpleで何もレンダリングされない）
→MolAtomRenderer::render()において、bonded/nonbondedの判断がおかしかったため。
別にchain _がおかしかったわけではなかった。
・2009/9/5完了、たださらにintensiveなtestが必要
resetProperty()（と、setProperty()）で、default flagを考慮したundo/redo実装をする
----------
2009/9/5
PDB, MolCoord関連、alternative conformationを認識されるようにした。
→もっと効率的な実装にしたほうが良いが、一応は動く
・SelCommandのtoString()を、SelNodesから構築するのではなく
compile時の文字列をそのまま返すようにした。
●完了
selectionで、around, byresの実装を復活
----------
2009/9/21
・完了
TraceRendererでhitTest()すると、固まらないように
TopoDBで、cuemol1ではあったaliasが実装
TopoDBで、cuemol1ではあったstatic residue propertyが実装
----------
2009/9/23
完了：BallStickRenderer
完了：AnIsoURenderer
完了：CPKRenderer
SplineCoeffSetなど？で、segment iteration codeがMainChainRendererと
かぶっているので、共通にしたい
（↑selectionに関係なく全体のsegmentを作る必要があるのでMainChainRendererと
共用はできない。）
↓完了
SplineCoeffでSpline補間の媒介変数tに残基番号を使用しているが、
insertion codeがある場合におかしくなるので、
残基番号とは関係がない単調増加する整数を使用する必要がある。
（ResidIndex --> tのテーブルが必要となる）
----------
2009/9/27
完了：
selectionで、altconfを指定できるように (name CG and alt B など)
selectionで、名前に関してnullの記述を導入，alt null,Aで主要なconformationを選べる．(chainは未)
selectionで，hierarchical (A,B.1:100.C,N,O,CA)形式を，andでなく独自のノードとして実装
A.123.CG:A形式は，あまり実用性がないと思われるので，保留
selectionで，aliasを定義して，使用できるように．
aliasは，システム固定のものと，各シーンで定義するものに分けられるようにする．(StyleMgrでStrDataとして実装・名前付きパレット色と同じ感じ)
→カスタム化可能な形で，proteinやhydrogenという表記が可能になる．
aliasのresolveは，selection評価時にしか行われない（compile時はidentifierとしてOKならエラーはでない）
→colorと違い，scope contextの問題は発生しない（常にapplyするobj(->scene)が分かるので）
・完了
アンダースコア_表記をやめて，chainもnullで選択できるようにすべき
→内部的には_になっているが，null ('')でも選択できるようにした．
・完了
selectionで、expand (around + それ自身も含むバージョン)を実装する
○TO DO
selectionで，neighbor (bondでtopology的に1段階で到達できる範囲)を実装する
----------
2009/10/03
Tubeの実装。（未完成）
panelOverlayにおいて、visible dataのparent indexが１大きかった
結果として getParentIndexの返す値がおかしくなって、
無限ループになりフリーズ。（なぜかLinuxのみだが）
正しい値になるように修正。以下を解決
Linuxでツリーボックスのコンテキストメニューを経由してダイアログを表示した後に、
ツリーの開閉を行うとフリーズする（結構致命的）
----------
2009/11/02
・完了
Tubeの実装、キャップ。（未完成）
getPropJSON,enumに対応
一部で、Nested propertyの変更Eventを、トップレベル（レンダラー）で拿捕してinvalidateを呼び出す実装をお粉アタ。
・【注意点】
tubeのsectionのように、固定の複合プロパティーを持つ場合は、手動でsetupParentDataをctorで呼び出してやる必要がある。
デフォルト値を持つプロパティーを含むオブジェクトは、他のオブジェクトのデフォルト値としてdefault=に記述することは出来ない。（未初期化の状態でそのオブジェクトのctorが呼ばれてしまうから）
例えば、TubeRendererのTubeSectionをデフォルト値としてqifに記述することは出来ない（そういう仕様）
・一応完了？ (問題点)
XMLへのserializationにおいて、objectの型名をtype属性で指定しているが、プロパティにtypeというのがあったら衝突が起こりプロパティを正しく指定できなくなる。
概念的には、プロパティにtypeがある場合は、objectの型は固定でよい筈（typeプロパティが型を規定していると考えられる）。
deserializizationではコードで指定された型のオブジェクトを割り当てるようにする（多分ctorで行われている筈）。
★書き出しに関しては一応実装，読み込みと更なるデバッグが必要
・一応解決済み
coloringがobject(mol)を参照する必要があるので、coloringのobjectへのattach/detach操作を実装し、
現在どのobjectに対して使用されているかわかるようにする必要がある。
→init()を実装
二次構造計算
グラジエント色
FancyColoring (sel->col list)
Tubeで試す
----------
2009/11/07
・完了
Tubeの実装、Ribbonの実装（一応完了？）
PaintColoringを作成
原子or残基(MolResidue/MolAtom)-->数値マッピングobject（coloring schemeの数値版）作成．
今のところScriptingインタフェイスはなし．
JctTableのproperty実装
・完了（？）
コンテナプロパティをreadonlyにしても，含まれているプロパティが変更されていたらシリアライズするように．
（中間ノードがreadonlyでも下位ノードにwritableがある場合は，変更をチェックする）
★書き出しに関しては一応実装，読み込みと更なるデバッグが必要
・完了(11/15)
PaintColoringのserialization/deserialization
・一応解決済み
Defaultの実装で、コンテナプロパティ内のプロパティのデフォルト値は、
そのコンテナが使われるケースバイケースで変わって然るべきであるが
(例えばTubeSectionのtuber値はTubeとRibbonで異なる)現在の実装ではそれが無理である。
↑Default styleという考え方で、場合に応じた初期値が設定できるので、それで良いのではないか？
----------
2009/11/15
・変更点
入れ子propertyは，LScrObjBaseで扱うのではなく，より外側のインタフェイスscripting interface等で処理して，
set/get propertyなどの高レベルインタフェイスでもドット表記のプロパティ名が渡されないことを保証する．
任意の部分で入れ子handlingが行えるように，NestedPropHandlerというクラスを作って再利用するようにした．
（js/spidermonkyではドット表記のプロパティ名は使われないのでjsインタフェイスはhandleNestedPropは不要）
・解決済み
Tubeで，selectionが効いていない (多分ribbonも)
----------
2009/11/23
・プロパティの現時点での実装
* Set
setProperty()
フロントエンド, main実装は LScrObject
デフォルト値フラグの管理、フラグを非デフォルト状態にする
プロパティ変更通知イベントの発生を実装
setPropertyImpl()を呼び出す
setPropertyImpl()
Middle-end, 実装は 各クラス毎にマクロMC_PROP_IMPL2で、
mcwgen3により精製されたコードで行われる
単にqlib::LWrapperImpl::setPropHelper<WRAPPER>()を呼び出す
---
↓以下は非公開interfaceと考える
qlib::LWrapperImpl::setPropHelper<_Wrapper>()
Backend
FuncMap::setProp() Backendを呼び出すFuncMapはwrapperのスーパークラス
this->setupParentData()を呼び出し、m_thisname, m_rootuidの維持を行う
FuncMap::setProp()
Backend、resetPropとの共用部分
funcmapから対応するfunc tupleを検索
LVarArgsの作成(と破棄)
func tupleに登録されている関数の実行
（登録されているのはmcwgen3によって生成されたsetter set_[X]）
set_[X]()
Backend
mcwgen3によって自動生成されたstaticなsetter関数
==========
* Reset (default値に戻す操作）
resetProperty()
フロントエンド, ユーザAPIレベルのインタフェイス、LScrObjBaseで実装
既にデフォルト状態の場合は何もしない
非デフォルト状態の場合は、resetPropertyImpl()を呼び出す
イベントの発生を実装
→style sheetがある場合は、このレベルでstyle値をdefaultとして扱うようにする
resetPropertyImpl()
Middle-end, インプリレベルの内部API, MC_PROP_IMPL2()マクロで各クラスにおいて実装されている
単にLWrapperImpl::resetProp<CLASSNAME>()を呼び出すだけ（真のデフォルト用の実装）
---
↓以下は非公開interfaceと考える
LWrapperImpl::resetProp<CLASSNAME>()
このレベルの関数は真のデフォルト値に特化した実装で、style sheetにawareである必要はない
FuncMap::hasWProp()で無かったらfalse
FuncMap::getDefVal()でデフォルト値取得、無かったらfalse
FuncMap::setProp()でデフォルト値に書き戻す
parent data周りの調整を行う
==========
・resetAllProps()の実装が、非公開interfaceを使って独自に実装されているのは良くないのでは？
↑これはctorでともかくもデフォルト値に設定するためだけの内部仕様と考えて、
このままで行くことに。
→APIで全リセットが必要な場合はenumerationとresetProp()を組み合わせればよいので。
○resetAllProps()が不必要に呼ばれないように何らかの対処が必要
・スタイルシートの実装
Leafプロパティーについてのスタイルシート実装（入れ子も含めて）は一応完了
StyleSheet classの実装(スタイルシートの実装本体)
StyleSupports interfaceの実装、いまのところRendererのみがサポートする
→applyStyles()の実装がメイン
StyleScrObjectの実装
→resetProperty()の実装がメイン
・Rendererのスタイル設定についてserialization実装、一応動作確認
・Nodeプロパティー(coloringなど)の実装
LDom2Nodeからインスタンスを作成して設定する必要がある
○Style変更についてのイベント(applyStylesで発生するだろう)がまだ
○Style設定についてのUndo/Redo(applyStylesで発生するだろう)がまだ
↑style設定GUIを作るときでよい？
○Style自体の編集変更についてのeventなどが未実装
↑style編集GUIを作るときでよい（延期）
==========
2009/12
rendering用scene書き出しの実装
POV-Ray書き出しの実装
・解決済み？？
StyleMgrにcontextの概念をもうけた．
Scene::display()の開始と終了時にcontextをそのsceneのIDに設定する
その間に行ったstyle/palette等の解決はscene ID --> globalの順で行う（scene localの定義が可能になる）
・解決済み？？
Materialの概念を導入する必要性
最低限：Renderer毎に指定可能
２段階：Colorが指定できるところはできるだけmaterialも指定可能に
material name --> material params (Table)が必要, paletteに類似
material paramsは，書き出しtarget，display contextの実装毎に異なる
↑２段階相当を一応実装．colorとmaterialの概念が別々になっている．
出力rendererによってはmaterialのみで色を指定できる場合があるので問題があるかもしれない．
・一応実装
Local色を定義する場合に，既存の定義色を加工（演算）して定義できるようにした．（透明度の増減，輝度の増減など）
Local定義を読み込み中でも，Local中で既に定義されている色は参照できるようにした．
定義はファイル中で出てくる順番に行われている。
color, material以外は一様の規則で文字列データを定義できるようにした。（selection等への応用）
・実装
Scene reader/writerを作った。StreamManagerで他と同様に扱うようにした(category ID 3,4)
Sceneのreloadを行えるようにした
・実装
分子選択でマクロを使えるようにした。定義はstyle中で行うようにした。
・実装
Styleの外部ファイル定義を可能にした．書き出し時には，ファイルへの参照として書き出される．
・実装
シーン中にStyle記述が複数ある場合，後に定義された方から遡って順に参照されるようにした．
→後方で定義したスタイルで前方のものを上書きできる．
○問題点
Style以外のstylemanagerの内容を，読み込み時の情報を失わないように
書き出すのが困難．特にColorが問題．
透明度の増減，輝度の増減などmodificationを行った色について，その情報が失われている．
全てLDOM2Nodeで保持して，呼び出し時に必要なobjectに変換するなり内容を参照するようにしなければならない．
○問題点
StyleMgr書き出し時に，保持しているLDOM2Nodeのdeepコピーを作らないと，serialize後に破棄されてしまう．
○TO DO
scene内部で定義しているstyle, palette等はsceneファイルに埋め込んで書き出せるようにしたい．
・実装済み
materialを色毎ではなくrenderer毎に一括設定できた方が良い
==========
2010/01
・MacOS X buildではデフォルトでlibtoolizeがない。
glibtoolizeというのがあるのでそれを使用するようにする。
・MacOSでのbuild要件(prerequisites)
- boost-1.39以降
date_time, filesystem, iostreams, program_options, regex, system, thread
はlibraryをbuildする必要がある。
そのままbuildすると64bit binaryのみできるので、bjamで
architecture=x86 address-model=32 link=shared,static threading=multi
を指定する。
- xulrunner-sdk（とruntime）
sourceからbuildする必要はないが、sdkのみだとlibglibなどがないので
mozillaのbuild環境は入れる必要がある。
sdkのみだと、package作成時に必要なFrameworkが入っていないのでruntimeも
installする必要がある。
【2010/01/14】
・実装
GeomLineに相当するAtomIntrRendererを実装．
前バージョンの形式だとXMLによる記述が困難（scriptingが前提となってしまっている）．
XML表記を考慮して，指定した原子（選択）間に点線を引くような実装にした．
そのため，MolCoordやSelCommand, MolAtomが前提の実装となっている．（->molvisに移動）
【2010/01/16】
frameworkをxulrunner1.9.2rc1にバージョンアップした（JITの効果か，若干起動が速い？）
・実装
ScenEventにscene loaded eventを追加した。
イベントは文字列プロパティとして保存され、イベント発生時にeval()されるようになっている。
引数（イベントターゲットのobjectなど？）を使えるようにする、などの工夫が必要か？
【2010/01/19】
xtal, DensityMap, MapMeshRenderer, CCP4MapReaderの移行と動作確認，一応OK.
●解決済み
DensityMap等、非MolCoord objにでもSelectionRendererが(例外が出つつも)attachされてしまうので
されないようにする
【2010/01/23】
SSM superposeをcoot/libssm/mmdbから実装
【2010/01/24】
XULのopenPopupの出る市がおかしかったのを修正
★ イベントモデルについて
Scene, Object, Renderer, Viewがそれぞれ独自のeventを発生しうる
（それ以外にもproperty eventが発生しうる）
Object, Renderer, Viewは全てSceneに属しており、
これらで発生したeventはSceneでrerouteされる。
Sceneとそれに関連したobjects eventを全て拿捕したい場合は、Sceneのみlistenすればよい
（わざわざsceneに追加されたかどうか監視して各objectsに対してlistenする必要はない）
個々のレベルでlistenしたい場合は、対応objectsに対してのみlistenした方が効率がよい
（SelectionRendererがMolCoordの選択変化に応じて表示を変更する等、renderer<->object
連携はこちらの方が効率的）
【2010/03/06】
・実装
object読み込みをloadObject()を廃止して，reader作成→object attach→read→破棄
の順でscriptから行うようにした．
→Readerのoptionがscriptから設定可能になった
・実装
Readerのoptionの違いによりsceneのdeserializationが変わってきてしまうので，
objectにReaderのoptionを保持させて，serialization時に
roptsというタグをもうけて，Readerのoptionを保存するようにした．
Readerのoptionは，source, srctype属性と同等の物である．
・実装
StreamManager.createHandler()にnicknameだけでなくカテゴリーIDを指定するようにした．
【2010/03/14】
・実装
surface module作成
gfx::Mesh作成
MolSurfObj, MSMSFileReader, MolSurfRenderer作成
ElePotMap, OpenDXPotReader作成
【2010/07/10】
・実装
mcwrapgen3.plを，Perl moduleで実装する．（ファイル分割が可能に）
mcwrapgen3.plで，JavaScript wrapperを自動生成するようにする（jsモードの追加）
→依存関係のトレースがややこしくなっている．wrapper jsが無くても自動的にmcwrapgen3.plが実行されないため，再度ビルドが必要になる．
→XPCOMのインターフェイスでjsapiを扱えるようなので，そちらにシフトすることも考える？
・Callback登録関数(object<LScrCallBack$>を引数とし，登録整数IDを返却するmethod)は，callback object１つのみを引数に取り，整数値を返す(invokeWithCallback1で呼び出す)，それ以外は不可
(ただ，invokeWithCallbackNで，第２引数以降は任意，というのもありかもしれないが，今のところ用途がないので実装していない)
【2010/08/25】
・実装
OpenGL関係をnspluginに依存しないように設計できるかトライ（キーボードイベントやマウスカーソルなどで不都合があった）
→一応OSX Cocoaで実装，Win, gdkともに可能っぽい
XPCOM native widget, Win初期実装完了
tabmolviewの，XBL中のコードをtabmolview.jsに移した
・メモリリーク問題：一応解決？
Sceneのscriptによるevent listener, 特にObjPanelが終了時の条件でremoveされないことが分かった．ObjPanel.fini()が呼び出された時には既にsceneがorphan状態(SceneManagerには所属しないが，何かしらによって参照されているため破棄されてない状況)になっている．→一時的な対応策として，Sceneのdtorで残ってしまったscript callback objはdeleteするようにした．
ScrEventManagerを導入することで以下の問題は解決しているはず（cuemol native objectがscriptを直接参照していることはないはず・全ての呼び出しは，event managerのslotを経由する＆slotはJSのGCの管理範疇である）：
orphan状態のobjectが誤ってeventを発生させた場合に，破棄されたscriptを参照して落ちる可能性をはらんでいる．ObjPanelによってremoveListenerを正常に呼び出すように改善すべきではある．
★DOM Inspectorを組み込んだ．CVSにはdom inspectorが入っていないので，chrome/inspector.jarを手動で配置しなければならない．
★Jetpack SDKを使用するようにした．
CVSにはjetpackが入っていないので，手動でresources以下に入れる必要がある．
resources/harness.js
resources/jetpack-core-lib/*.js
以上のファイルは，jetpack SDK distributionからそのままコピーする．それ以外のcuemol2特異的なファイルはCVSに入れた．
harness.jsは
/jetpack-sdk-X.XX/python-lib/cuddlefish/app-extension/components/harness.js
をコピーすること．他にも同名のファイルがあるが，それでは動作しない．
現在Jetpack SDKは0.7でないと動作しない．(0.8から結構大幅な変更があるためjpk_hns.js？の変更が必要)
【2010/08/28】
・実装
sidepanelとmanagerを実装．closeとcollapseを実装．
●解決済み
パネルのdrag and dropの実装が中途半端．hiddenのpanelがあるとバグる．
以前のsaved dataから新規パネルが追加された時に，
そのパネルがrestoreDefaultを実行するまで非表示かつonLoadが呼ばれない状態になる．
済：メニューからのshow/hide
済：パネル位置等のpersistency
修正済み：問題点
treeの内容がsidepanelを移動すると消えてしまう．
DOMイベントハンドラーによっては，ハンドラーの指定方法によってDOM階層をいじるとおかしくなる現象が見られたので
（特にpanelbarのbuttonで発生，修正済み）関係があるかもしれない．
いちおう実装済み：treeの実装をMVCに基づいて容易にするようなクラスが必要．
object-menulistを実装
フィルターを指定して，objectを選択するdrop-down list box，汎用的に使用可能なような物を目指す．
symm moduleを実装
symm-panelを実装
MolCoord, DensityMapについてはセル長などが表示できるが，未だ未実装な機能が多い
●完了
change/edit symm info (+dialog)
show unitcell renderer
show symm renderer
【2010/09/11】
・実装
Scriptからのevent使用方法を若干変更した．
各listenerが各々XPCOM object(qIScrCallBack)を作って，nativeから直接呼び出すようにしていたのをやめて，
大元のevent managerのみqIScrCallBackを使用して，jsのevent manager <--> qsys::ScrEventManagerが
通信(?)するようにした．script側のcallback obj (object or function)をnativeが保持するのではなく，
js event manager (jetpack moduleを使用してsingleton実装)が保持するようにした．
この方が，objectの寿命の問題などを回避しやすい．
qsys::ScrEventManagerで，event filterの機能を実装した．
指定した組み合わせのみ，該当のscript handlerが呼ばれるようになるため，
不必要にscript/nativeの境界を行き来する必要がなくなる．
実際にfilterに一致した場合のみLEventがjson文字列を返し，
それがevent manaterでobjectに変換されて，listenerに渡されるようにした．
いちおうJSONの生成と，parseは必要時のみによくせいされるはずである．
object-menulistは対応
完了：
workspace-panelを対応させる
★DOM Inspectorの組み込み
・inspector.jarをchromeに配置
・defaultsにもjsを配置
・componentsにもjsを配置
この二つを忘れると，flasherが動かない＋XBLが展開できない
【2010/09/15】
・densitymap-panelを追加
実装はまだまだ不完全
・JS wrapperを，Cu.import()を使って行うように変更した．
・getClassObj()が返すmetaclass（の名前）と，wrapper JSが対応していないと
wrapperがload出来ない（希望としてはsuperclassのwrapperを読み込んでほしい）という
不具合があったが，LScriptable::getScrClassObj()というinterfaceを追加して何とか対応した．
・上記を除いては，一応大きな問題はないように見える．
・ScrEventManagerで，event target typeの指定を，値指定でなく，ビットマスク指定にして，
object+rendererをlistenする，というような組合せ指定が可能になった．
・sidepanelの，open/close menu, session save/loadを実装
・treeviewのopen/collapsed stateの保存を実装
・workspace panelの表示非表示buttonを実装
・molstruct panelの初期実装
【2010/09/20】
jarファイル化を試みる．mozillaのmake-jars.plを使用
zip圧縮プログラムが必要．pathが通った所に，zip.exe (mozilla build toolsのinfo-zip付属)を置いて使用する．
実装
・windows QSC documentまわりの整備，installerでの関連づけ
・documentアイコン作成
・起動時のコマンドライン引数でqscファイルを指定して起動すると，読み込むように
・第2インスタンスを起動した場合に，コマンドライン引数指定があった場合も(qscなら)読み込み対応
・sceneのmodified flagを(undo/redoが正しく実装されている限りは)正しい値を返すようにした(単にundo size>0-->modified)
・sceneのsave, open, saveas, reload周りを正しく動作するように実装した
・CameraEvent周りの実装
・workspace panelでcameraを扱えるようにした（不完全）
・paint-panelの実装
・NamedColorが，様々な場面で参照されるため，NamedColor自体にScene IDを持たせるようにした．
→そうしないと(特にsceneと関連が弱い)GUI JSからcolor codeが参照された場合に，色が決められなくなる
逆に，NamedColorをsceneをまたがってコピーすることはあまりないと考えられる．（GUIで出来ないように制限する）
・NamedColorが生成する時に，SceneIDが分かっている必要がある．
・NamedColorは殆ど（全て）fromStringS()で生成している．（文字列からのproperty暗黙変換）
★重要：
色のfromStringS()変換が起こりうる場面で，全てStyleMgr::push/set ContextIDで現在シーンのIDをセットするようにする必要がある．
今のところはSceneXMLReaderが最も重要な場面であるが，
★GUI実装でも，暗黙変換が生じうる，color propertyを設定する場面では，全てpush contextをしておく必要がある．
・解決済み
以下は、
StyleMgr::push/set ContextIDを実装し、
積極的にStyleMgrにcontextを設定することで解決。
Scene::display()外でcolorやmaterialの参照解決を行うと，local定義が参照できないという問題が起りうる．
いまのところそういうコードはないので問題は起きていないように見えるが．．．
（Styleに関しては，解決時にscope IDを指定する必要があるので問題は起らない）
【2010/09/26】
・paint-panelの実装
remove entryを実装した.
changeのundo/redoを実装した.
addのundo/redoを実装した.
・PaintColoringの実装