摘要： 有一些松懈，罪过罪过，警告自己一下。但是没有闲着，主要是Chrome浏览器部分的代码着实庞大复杂，牵扯到的新技术技巧很多，正在全面的了解其进程模型、线程模型、自升级策略、底层消息框架View框架的应用细节、应用系统的通知模型、配置系统、扩展系统、各种Windows奇技淫巧等综合起来，确实需要耗费大量精力。这些东西不像底层代码那样几乎是完全可复用的，有很多东西是浏览器相关的，我目前并不想积累。有的时候会替别人问自己：你有必要搞那么复杂嘛？你到底想要搞一个什么东西？你这东西能不能用？等你全部整明白了是不是已经淘汰了？互联网客户端未来还会不会有希望？我想首先我不是那么急功近利，我的基本生活不是以此为 阅读全文

摘要： 最近比较忙，各种原因，对界面框架做的工作如下：1、维护更新至chromium.r804142、开始着眼Chrome浏览器架构，框架、插件机制、主题、多进程/线程方面3、工作的目标做了适当延伸，暂时命名x-framework，并尝试模拟实现一个类Chrome的UI作品。4、界面方面进度不大，主要是不断研究、尝试、走弯路和改进过程，临时性的截图： 阅读全文

摘要： 前段时间的工作1.2d绘图引擎迁移回skia平台2.跟进到Chrome源码的chromium.r78515版本3.ScrollView、Menu等UI元素移植4.修改Chrome的一些Bugs或不足5.目录的整理、调整6.开始以教程的形式深入理解整个UI框架, 发现其中的问题, 为下一步扩展打好基础UI库项目的依赖在library\depends.txtUI库的Bugs在library\bugs.txt所有不确定的地方在代码中均有WLW TODO标记之前的test_base test_view项目即将废弃, 不要再尝试编译, 会以教程的形式体现近期工作跟踪chromium最新源码, 修改Bug 阅读全文

摘要： 下一步计划：1、gdiplus->skia: 之前移植的就是skia，后来觉得开源的skia代码量大且需要额外包含头文件，怕他人觉得麻烦就自己替换了gdiplus.因有人提及，自己也觉得有点画蛇添足，故改回。2、更新至最新的的Chrome代码，包括结构的合理性和bug的修改。3、ScrollView以及Richedit的ITextHost处理实现无窗口的编辑视图。 阅读全文

摘要： 初衷一直希望VC开发者能够方便的开发出细腻高品质的用户界面。我喜欢C++，选择的平台是Windows，所以大部分时间用VC。我自身不排斥其他技术或者开发语言或者开发工具，都去了解，了解的目的是想吸取好的思想补充VC开发方面的不足。从事界面开发方面的研究有5年了，学过很多，尝试过很多，失败过很多，但是没有气馁。感谢开源，尤其是谷歌的Chrome开源，使我再次提高。在论坛和代码网站，都能看到一些界面方... 阅读全文

摘要： 就目前我对界面的了解，经典的有2种方案，分别映射到客户端和互联网：一种是windows的界面管理；另一种是html的渲染模型以及交互驱动。前者的优势在于便捷直观的反应了常见的交互视窗；后者的优势在于强大的组合构造任意交互视窗能力。 这两种界面方案后面的支撑都是非常难以实现的，也正是计算机出现给普通用户的基础。由于之前对于ie的源码进行了研究，零零散散抽取的基本实现源码有30m之多，模型之复杂使得在... 阅读全文

摘要： 根据经验加上参考一些其他库，总结了一些基础设施分享。本次只有基类窗口以及透明窗口的基本实现，至于alpha gdi操作由于不打算涉及（方向原因，工作量等），透明窗口的矢量渲染部分借助于gdi+。由于内容较少加之时间原因，解释部分忽略。 下一步建立tls机制，作为一个完备的库方案，这是必须滴！！！ src 找个opensource forum 是必要的。 截图： 阅读全文

摘要： 经过几年的技术沉淀，越发理解“工欲善其事必先利其器”的重要性，基础设施的完备加上逻辑的缜密，常常能带来水到渠成的享受。 作为一个软件开发者，最大的荣耀莫过于自己的成果被分享。我以为分享有2种：1是与最终用户的分享；2是与软件开发者的分享。前者的分享取决于产品的运营（个人或企业），后者取决于技术的先进性，由于前者取决于个体的因素有限，故我偏向于第二种分享机制，所以立志于成为一... 阅读全文

摘要： 从来一次，记录下自己的点滴...... 阅读全文