主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃

标题党啊，还是应该乱弹12。

不过这个“鼠标引发的故事”的帖子中问题多了点，俺认为“妨碍”了河友的正确理解，是不是该打楼主的“屁股”？

1.别的OS俺不是太熟悉。Windows操作系统之上可用于C/C++ GUI开发的GUI Toolkit(俺对TOOLKIT这个词质疑，是否应该用FRAMEWORK？)，包括但不仅限于MFC(Microsoft Fundation Classes)。比如BORLAND就先后有OWL,VCL。MS自己有MFC和ATL(Active Template Library)。为什么？第一是MFC框架的笨重，第二是MFC不支持多重继承。第二点在“现代”C++开发中特别重要。没有多重继承，许多代码设计模式比较难于实现（这个东西非常的枯燥和“丑陋”，俺不想在这里多费口舌）。但是俺可以100%负责任地说，CHROME在其WINDOWS上的“窗口”部分采用的是ATL的框架 --- 或者说CHROME的“窗口控件类”（CHROME的术语叫VIEW类）继承自ATL的CWindow。

2.关键的问题LZ在其叙述点击过程中的不“全面”对河友的“误导”。XDJM们打过枪没有？没有打过枪的请先学习射击基本知识。打枪扣动扳机前瞄准不？如果你不瞄准的话，剩下的东西你也别看了。相比扣动扳机，瞄准是个“漫长”的过程（成年人可以类比ML中的“活塞运动”与“高潮”。）；扣动扳机仅仅是利用了瞄准的结果 --- 瞄准是为了射击（扣动扳机），射击必须依赖瞄准。。。。。。fire at will。

回到楼主的帖子来。楼主的叙述把WIBKIT描述的其笨无比，按下鼠标键，然后。。。。。。WIBKIT是如此动作的。慢慢慢！！！鼠标的光标是从火星上掉下来然后突然跑到render tree的某个NODE上吗？在on_mouse_click这个事件前，有无数个on_mouse_over和on_mouse_out事件，而且on_mouse_over, on_mouse_out和on_mouse_click统统都是WEBKIT(RENDER ENGINE)的派生事件。难道无数个on_mouse_over和on_mouse_out事件，WEBKIT都无动于衷吗？无动于衷这个提法本身就有大问题。为什么？鼠标的运动是一个“连续”的过程，一个新的鼠标位置事件（由操作系统提供）被WEBKIT可能解释为on_mouse_over, on_mouse_out，on_mouse_click。。。WEBKIT(RENDER ENGINE)解释的过程就是与某个NODE的“绑定”（over）与“松绑定”（out）过程，而且这个结果可以重复利用 --- 新的鼠标位置信息，检查上一个“绑定”的NODE，如果位置还在这个NODE的范围，继续发on_mouse_over，返回；如果不在这个NODE的范围先给先给node发on_mouse_out，然后“遍历”NODE TREE,看看是否给给另外一个NODE发on_mouse_over 。。。。。。，返回。在某个时间尺度上，on_mouse_click之前必定是on_mouse_over --- 正如扣动扳机的时候枪口停止运动(别和俺抬杠自动武器的连发，鼠标就是一个古老的土枪，扣一下打一发)。

1. GUI Toolkit

坦率讲，俺也同意你的观点。MFC也好，ATL也罢，已经不是toolkit，一个工具箱，想用就用不想用晾一边去。它虽然在操作系统以外，但是的确是系统必不可少的一部份。有点冤枉，如果说File System是OS的一部份，凭什么GUI就不是OS一部份？

但是，俺遵从Wikipedia。Wikipedia说那是GUI Toolkit，而不是Framework。好吧，那就工具箱吧。

2. ATL etc

GUI Toolkit的内容庞杂，历史纠结也深。应该单独写一篇。你看，把GUI Toolkit塞在Webkit event同一篇文章里，行文匆忙，涉嫌误导不说，读者也觉得累。这篇文章的内容太多了。

3. Event

还是前面说的那个问题，一篇文章不宜塞太多内容，累人，而且有可能误人。

本来这些内容都该展开来慢慢谈的。结果，因为担心篇幅太长，就从略了。从略，就有误导的可能。

那个click与WEBKIT(RENDER ENGINE)的问题可以先放到一边。如果不是真正对优化engine有兴趣的人相信不一定能深入其中，但是真正对非文本编辑器（比如CAD,CAM软件）有设计经验的人都会按那个思路来操作。

上面的人（比如CTO,或者乔布斯这样的CEO）务虚完成后，就是底下的DIRECTOR，PM,甚至SENIOR开始给这些人“擦屁股”。“擦屁股”就是真正的务实，比如要多少人多少时间，多大的预算。没有这些务实，务虚就是埃里森嘴里的网络计算机，雾中花，水中月。大公司务虚务错了没有关系，反正东方不亮西方亮，手下的人如果务实悟不出来也好办。CFO过来一下，公司手里还有多少现金?CTO过来一下,那个TOM的team实在是有问题，这么长时间都搞不定，打开你的雷达，去找个有类似东西的小公司，让CFO下面的团队看看能不能搞定它们。如果这个小公司后面能搞定，TOM的team就地解散，TOM本人的问题你自己看着办。

我们一个学期有图形学，编译和微机三门大作业，我当时还在跟老婆热恋。

当时和三个同学一起做图形学的东西,scope是：

1.一个DOS下面的图形界面，包括窗口，按钮，鼠标输入的3维旋转体建模，鼠标进行物体的三维移动

2.光线跟踪算法，计算透明物体在一个有bmp作为墙纸的场景中的render

3.三维视角模型，完整的文档

当时为了那个图形界面，我们从BC++的bitset开始写起，硬是在半个学期+寒假把这个东西给做出来了，从此以后，看到视窗模型和鼠标事件这些事情，就觉得很自然了。

实际动手做一遍，道理就明白了。

当然，这个过程是比较痛苦的。

在上图中，因为DOM的盒子模型，就是一个子节点通常是在父节点的盒子内部，或者说上方，所以DOM tree隐含了z-order：子节点的z-order大于父节点。

但是在两个子节点有overlapping的时候，就要看z-order来决定事件先传播到哪个子节点了。这种overlapping的关系，我推测应该是由render的顺序决定的，后来居上。

联系到以前说的三维DOM模型，render的时候，DOM在viewing port里面的投影不是严格的矩形，这个鼠标事件最后花落谁家，就比较难计算了。

我在第20篇，“结构与解构”一文的例子里，用到了z-order。注意看第20篇figure 1.，图中两行字浮在Einstein头像上。

本来想仔细跟踪一下z-order的实现方法，实际跟踪以后发现，涉及相当多的objects，为了突出重点，暂时不去深究。

大致说来，在render tree以外，还有一棵shadow tree，z-order里面的东东，都在shadow tree里放着。因为没有深究，所以不敢妄加评判，但是感觉与render tree平行着，再建一个shadow tree，似乎不是表现力很丰富的做法。

这明显是太细节的咚咚啦。

我个人感觉邓侃尺度把握的挺好

特别是cell phone行业。google关键词“webkit jobs",经济不景气中的亮点？

何不去硅谷。那地方比较活跃。

某个行业热度的重要晴雨表，更重要的是它代表着一种底下的潮流。因此既要看各公司的新闻发布会，更要看公司的招聘POST。