考虑到Microsoft平台上开发工具的特点，一个与XUL接近的GUI引擎必须能够充分发挥主流开发工具的效率、生产力，因此，对Visual Studio6以及Delphi、VS2005等的支持就成为一个必须考虑的问题。一般说来，一个GUI框架的轮廓，是很容易被XML清晰描述的，因此，我开发的出发点就选择在GUI框架的XML描述与创建这一点上。通常，人们对平面区域的规划、利用，基本基于两种基本的结构:1:Splitter;2:分页行为的标签出口，比较综合的GUI架构基本就是如上两类结构的复合，问题的难点是标签窗口，这类窗口的风格比较多，因此，对应的XML节点也就相对复杂一些。一旦框架描述完毕，具体的内容就可以“填充”了。针对MFC开发者，我们考虑其自身的特点，允许这类开发者将“原子”级别的组件实现为C++的CView对象，针对VB6开发者，允许开发者直接使用VB6开发的ActiveX控件以及ActiveDocument对象，特别，我们对.NET支持作了大量的工作，允许开发者直接使用大部分.NET User Control对象
全部回复（3 ）
只看楼主 我来说两句-
vincent_nk
沙发
(二:IE7，程序员的软件集成平台)
2006-11-26 20:15:26
赞同0
-
vincent_nk
板凳
这一点意味着什么?也许，实现一个类似的软件结构，真的会与现在的Web开发者写一个HTML页面相当。应用软件页面化是指将特定的桌面软件XML化，使得其软件结构可以用十分清晰的XML方式清晰描述，然后在运行时给予复原，这一技术处理，将极大地简化应用软件的写作，并使得动态软件成为可能。如上图所显示的GUI结构，通常的方案就是用代码技术实现，今天，这个传统的软件开发模式就要没落了，WWW进化十年催生的新技术将使得类似的工作完全可以与HTML开发媲美。我们面临的时代，将变迁为以文档为核心的时代，对用户可见的一切，基本上都可以表示为某种类型的文档，二进制为软件主体表现形态的阶段，已经开始渐渐失去其中心地位。
2006-11-26 20:14:26
赞同0
加载更多针对每一个标签页，开发者可以加载完全不同的GUI扩展，看上去很像一个类似“Eclipse”类型的集成环境，因此，以下问题就浮出水面:
1、 我们如何有效的进行针对IE的GUI扩展;
2、 一旦扩展成为可能，扩展模型能够与IE的内部机制(例如，内置的脚本引擎)相容吗?
3、 扩展界面能否自然的与HTML交互操作?
4、 我们考虑的扩展技术与主流的开发工具之间的“gape”是否很大?
5、 适合什么样的开发者群体?
6、 能否协调的建立桌面组件与WWW服务之间的桥接?
FireFox针对开发者提供的一个重要工作就是一个基于XML的界面描述引擎，即众所周知的XUL，关于这一点，Microsoft现在没有对应的工作，由于缺乏类似的技术，综合、复杂的GUI扩展就成了IE的一个缺陷，因此，为IE提供一个类似的引擎，就成了解决问题的关键。
考虑到Microsoft平台上开发工具的特点，一个与XUL接近的GUI引擎必须能够充分发挥主流开发工具的效率、生产力，因此，对Visual Studio6以及Delphi、VS2005等的支持就成为一个必须考虑的问题。一般说来，一个GUI框架的轮廓，是很容易被XML清晰描述的，因此，我开发的出发点就选择在GUI框架的XML描述与创建这一点上。通常，人们对平面区域的规划、利用，基本基于两种基本的结构:1:Splitter;2:分页行为的标签出口，比较综合的GUI架构基本就是如上两类结构的复合，问题的难点是标签窗口，这类窗口的风格比较多，因此，对应的XML节点也就相对复杂一些。一旦框架描述完毕，具体的内容就可以“填充”了。针对MFC开发者，我们考虑其自身的特点，允许这类开发者将“原子”级别的组件实现为C++的CView对象，针对VB6开发者，允许开发者直接使用VB6开发的ActiveX控件以及ActiveDocument对象，特别，我们对.NET支持作了大量的工作，允许开发者直接使用大部分.NET User Control对象
回复 举报
然而，今天的开发者，又是非常幸运的，亲历一个时代的变迁并不是一件容易赶上的事情，Web开发与桌面软件的开发在方式上正在逐步缩小差别，我们即将成为消除差别的见证者。这种差别的消失，将使得WWW上出现大量的有别于HTML的“物种”，因此，软件的定义有可能发生改变以适应WWW的变化。在与几位开发浏览器的朋友多次探讨之后，我意识到，浏览器应用是十分重要的应用，也许，浏览器应该成为一个应用的“起点”，也就是说，在特定意义之下，任何一个软件都可能成为一个“浏览器”。现在的软件开发，还存在很清晰的界线，这种界线的存在使得软件彼此不同，这是传统开发模式带来的固有弊端。浏览器的开发能否成为消除这个弊端，进而促使“柏林墙”倒塌的导火索?大约一周前，我曾经拜访Maxthon，毋庸置疑，在国内众多的第三方浏览器之中，Maxthon是当之无愧的王者，隐约之中，可以感觉Maxthon在酝酿着一些变化，在WWW内容为王的时代，任何人都可能打算尝试变化。曾经有过考虑，也打算开发一个第三方浏览器，当考察几款第三方浏览器后，这个打算被否决了，原因之一是大家的工作相似的地方太多了，尽管“各村有各村的高招”，但除了一支独秀的几款，其他产品很难有所作为，当然，这是个人观点。根据个人的观察，国内的浏览器开发也许陷入了一个“歧路”，大家将侧重点几乎都放在“细节”方面，强调“用户体验”，例如，“鼠标手势”、广告拦截、Flash处理等等，这些东西是Microsoft浏览器的盲点，也许就是这些盲点的存在，使得第三方有了生存的空间。我们习惯了在本土内进行厮杀，在一些细节上，大家彼此的消耗着，几乎在做同样的事情。在今天的硬件条件下，我们将技术细节定位在资源消耗、速度对比等方面，我们没有在观念上产生突破，我认为这是很不可理解的事情。之所以如此，也许是因为我们没有意识到我们是身处大海之中!出于殖民的需要，西方人勇于探索大海，而我们却封疆闭土，没有观念上的突破，导致我们的定制化浏览器彼此越来越像，最终结果可想而知……。
浏览器能否作为一个应用开发的起点?这是我一直在思考的问题，也是一年来为之努力的目标。就软件的可扩展性而言，IE并不比FireFox差，即使今天的IE7，在插件开发的基本方法上依然停留在1996年的SDK水平上，这说明什么?只能说明策略上，IE7之前，Microsoft没有重视这个问题。我认为，绝大多数的第三方特色，在现在的IE框架上，都是可以实现的，从这个方面理解，许多第三方浏览器能够存在，的确是很奇怪的现象。就基础框架而言，IE本身的架构，第三方是无法与之相比的，那么，Microsoft失误了吗?Microsoft插件开发的门槛过高也许是导致IE不容易扩展的关键原因。第三方浏览器并没有在本质的一面增强IE，许多安全方面的问题，还是借助IE本身，因此，基本就是IE的另外一个“壳”。我考虑IE开发的出发点也许与绝大多数浏览器开发者是不同的，IE占据绝大多数的市场份额是不争的事实，因此，如何更好的利用IE，就成了一个思考点。如果能够充分利用IE的好处，使得开发者能够构造更好的网络软件，不失为一个明智的策略。那么，IE有什么值得利用的优势?我认为至少有以下几点:
1、 IE具有最广泛的用户群体，这是最重要的理由;
2、 IE的HTML模型可以使得软件得到极大的灵活性;
3、 IE具备一个健壮的脚本描述引擎，这个引擎，明显的优于开发者自身集成的脚本引擎;
4、 IE自身具有健壮的插件体系，对软件开发者而言，是一个天然的资源;
5、 在IE框架内，软件功能的“柏林墙”几乎不存在;
6、 可以直接将本地软件提升为WWW风格的软件系统。
基于以上几点，我认为:
1、 建立一个灵活的寄居在IE框架之上的开发环境是十分必要的;
2、 为IE以及IE控件提供一个灵活的扩展框架，可以良好的促进IE以及第三方应用的开发;
3、 第三方应用开发与IE的有机集成，会给WWW提供新的活力。
那么，这些目标能否实现呢?答案是肯定的。
在一个月前，Microsoft正式发布了IE7，这是5年来IE的一次重要升级。与IE6相比，IE7明显“漂亮”许多，在这里我们看到，Microsoft不再固执，已经采纳了一些备受用户喜欢的第三方特征，IE7与IE6一样，本身是多线程的，只不过显得更紧凑。在许多开发者的视界里，IE是一个浏览平台，大多数情况下，IE是用来浏览网页的。但我们深入其内部的时候，我们可以得出一个结论，那就是，IE7是一个绝好的GUI框架，即使是一个很优秀的技术团队，企图开发一个与IE7相当的软件框架都是相当困难的。我们非常高兴的看到，IE7给GUI扩展提供了很广阔的天地:
回复 举报