本来是想一周坚持写一篇博客来记录下自己学着写编辑器的进展的，不过总想着写好一个阶段再写一篇总的能有写“内涵”的，于是乎拖着拖着一个月又过去了，最近想想自己又不是高手，blog还是该没事就写点，不管是脑残的错误
还是幼稚的想法都该写下来。
4月中，编辑器底层大改；可以说咱的编辑器本来的大部分结构学的是Ogitor，不过实际上程序最下面的结构当时大家没学Ogitor（最下面的结构指的是Ogitor对于编辑器对象的具体属性都采用了专门的属性容器，OgitorProperty<T>，当时就以为ogitor只是为了解耦的），等我们把大部分基本的功能都实现了（地形，光照，实体，地形编辑，草体），回过头来想加撤销还原的时候发现不好办了，（想一想，光以基本变量（bool等原子类型，Ogre::Vector3等基本数据类型）来保存具体编辑器的编辑属性的话，根本没办法撤销还原）于是我就从底层改起了。
1.去除过多的单件： 这一点是我和兄弟相当赞同的，过多离散的单件往往在方便的同时破坏了整个程序的结构，改之和Ogitor已知，采用基类的ObjectList的方式来管理所有的编辑器对象实例，这样所有的类都能得到统一管理，查找指定对象只需以它的类型来查找即可，需要单独更新的对象则加入到UpdateList中，然后在迭代更新列表逐个更新即可，在不用我们自己在主体里来回添加Update语句了。（这主要是为了解耦）但我想了想有个地方还是没学ogitor，它里面每个编辑器对象都有所有的parentEditor，这样则形成一种树形结构，这样的设计更加紧凑，不过我们暂时觉得没什么太大必要加，就放弃了（开始对OgitorProperty<T>也是这个想法
）。
2. 属性注册： 属性部分所有内容，我还没全看明白。一是由于撤销还原还没弄，二是信号那块我也还没加（虽然树形类的代码是全扒过来了...）。不过就我目前看的部分而言，Ogitor这帮家伙写得还真棒，利用模板trait来调用对应变量类型函数（第二次见，第一次在STL源码剖析里，就那块和开始的部分我能看懂...），光看到这个内容小菜我就兴奋不已了。注册的部分实际不难，好好看看PROPERTY_PTR和SETTER，GETTER这些个宏就能明白，无非是在对应编辑器的工厂map表里先添加定义，然后利用这些个宏为mProperties添加属性变量，以及变量相关联的设置其数值的函数。
调试中犯的一些搞笑错误： 1.前天在重写BaseObject的GetNode函数（返回编辑器对象所在的场景节点，若是基类则为NULL，只有是NodeObject或其以上的才有值，这里没学Ogitor的parentnode），发现程序里实际调用的时候就是不调NodeObject::GetNode而是调BaseObject::GetNode()，改了会都对C++产生了疑惑。。。还专门写了测试来看看究竟调用哪个，结构也应该是NodeObject::GetNode，这问题足足花了我二十分钟的时间，才发现自己在继承方法声明上忘记加const了。。。那一刻的感慨啊。。还是得经常把Effective C++拿出来摸一摸，翻一翻的。。
改着改着，突然在想：当有高手源码借鉴的时候，作为我这样的小菜（指的是C++学了1年多，功底自认为不错，但缺乏实际经验的人），是改照单全理解了再写还是边理解边按自己修改的较差方法去实现呢？我觉得是后者，因为后者总是需要去修改，而在修改的过程中才是存疑解惑的过程，这个过程中小菜才能明白为何高手如此“麻烦”地绕道偏行。还有，正如tonykee说的，编辑器的确是个无底洞～～要懂得适可而止的。
分享点新闻： 1.GoogleCode和SVN升级为2G了（具体貌似是1G更新空间，另外1G存储，这一点没太明白。。），嫌sourceForge麻烦的有福音咯～～
2.Ogitor这帮家伙更新的越来越快了，当时还给他们提意见说应该做成简单material脚本编写的编辑器，刚说完，人家就回说：已经开始做了
顺带一提，Ogitor有中文版了，感谢Coho的翻译，虽然有些地方还没翻译好，不过我空了也会帮帮他们忙的
3.星际7月27日预售，很期待它的银河编辑器啊～～
这两天完成撤销还原后再更新吧，希望我写的乱七八糟的东西对大家有帮助。