All Stories
作为一个文本编辑器，一个IDE，不能通过命令行参数打开一个文件，是很说不过去的，于是我就想加这个功能，不料却意外地困难！
首先考虑当前没有已经运行的本程序的进程，通过命令行参数指定一个文件后，最wxApp::OnInit的最后返回前，主窗口已经正常创建显示后，可以将文件路径传递给主窗口，让主窗口打开这个文件。照理说，这应该是一个很平常很普通很正规的流程吧，结果不知道为什么，打开文件这个操作会让程序崩溃。
然后考虑当前已经有运行的本程序的进程了，这时如果再通过命令行参数指定一个文件，启动新进程，就需要让新进程通过IPC向老进程发送通知，让老进程来打开这个文件，而完成通知工作后新进程就可以退出了。这也是一个很平常很普通很正规的流程吧，于是我查阅了wxWidgets的关于IPC的文档和sample代码，感觉还是很简单的。在Windows平台上有两种选择，分别是基于DDE的实现和基于Socket的实现，可以用相同的代码，最终通过预定义宏来开关选择，可是最终仍然是问题重重。使用基于Socket的实现，进程在第一次启动时，Windows会弹出消息框询问是否允许该程序在本地打开一个网络端口进行监听，这就已经有点小题大做了。然后当新进程给老进程发送通知时，老进程不是没反应，貌似根本没收到通知，就是崩溃！如果切换成基于DDE的实现，倒是老进程能收到通知，但有个很奇怪的现象是从收到通知开始的那个wxDDEConnection::OnExecute函数开始往下走，wxChar*或wxString不能正确转换为const char*（因为我是使用Unicode编译项目，而字符串要以const char *传递给内嵌的Lua解释器），反正就是无论用wxString::mb_str()，还是直接的wxConvLocal::cWC2MB()都不能正确返回转换后的const char*。试了一下C runtime中的wcstomb函数，倒是能正常转换。但在Lua回调宿主程序导出的函数时，该函数将wxString转换为std::string作为返回值传递给Lua，无论用哪种转换方法，结果也会崩溃！
到此为止，所有尝试均告失败，加入命令行参数打开文件功能仍然没有实现，郁闷！
昨晚突然发现twitter的hosts ip不能用了，在just-ping.com里找了一遍api.twitter.com的ip，挨个儿ping了一遍，没有一个能ping通的。真是太杯具了，如果用Mac OSX，倒是没什么影响，反正我都是连上SSH后进行全局代理的，Echofon for Mac本身不能设API和Proxy，全靠这样SSH上去用的。但在Windows下就很无奈了，我一般用TweetDeck或Seesmic Desktop2，这两个东西一个用的是Adobe AIR，另一个是用Microsoft Silverlight，也都不能设置Proxy，而且Windows貌似也没有可以将SSH设置成全局代理的功能，于是头疼了。办法是有的，可以用SocksCap之类的东西单独设置某个程序进行Proxy，唉！
我得加快动作了。
上午大牛在twitter上DM我，说他升级了，6号时小吉给他生了个儿子。恭喜一下。
前些日子小思思发短信说生了个女儿的，而且还是比预产期晚了10天的，前天还用邮件给我发了张小侄女的照片。眼睛黑黑亮亮，脸圆圆肉肉，好可爱的。
再之前，大约半年前，孙同学和薛mm也发短信来说过生了女儿和儿子。
呃，我们这批同事中，大概最早的是宣宣的女儿了。
真是一帮幸福的人哇！
突然想再整一下wxMac，之前曾经编译过，也编译出静态链接和动态链接的库了，记得也生成samples的可执行文件了，今天找了一下，那些samples的可执行文件找不到了，随便敲了下make，发现连头文件都没有找到，应该是wx-config没正确执行。然后好奇看了一下readme，赫然发现wxWidgets/Mac doesn't come with any guarantee whatsoever. It might crash your harddisk or destroy your monitor. 这个太夸张啦，不敢用啦，甚至开始觉得是不是以后别的用wxMac开发的程序也要先检测一下然后不用了呢！那个杯具的CodeLite和Code::Blocks都是用wxMac的呢！反正我是不想再用了。
下午尝试给CodingStudio加入命令行打开文件的功能，可是怎么整都是搞得程序启动就崩溃，郁闷了！
于是很有些后悔当初采用了wxWidgets，而不是Qt。但是想想以当时的情况，确实再来一次，很可能还是不会用Qt。当初对Qt很是不满意它对所有控件都是自绘，而不是native的，而且觉得Qt需要moc一下很无语。最关键的是当时参考了大量CodeLite和Code::Blocks的源代码，没办法啊，对于一个新接触的GUI framework，这是最直接有效的办法了！
哦，对了，今天的消息，国人得到Nobel Peace Prize了，具体情况，咳咳，不明真相的童鞋，需要当一回红杏。
Saezuri是个UI设计得很精致的Twitter客户端，作者是个日本人，基于Adobe AIR开发。
Saezuri支持多账号，但添加账号的方式稍显繁琐，一方面需要Saezuri本身可以访问twitter.com，另一方面还需要浏览器可以访问twitter，以获取一个PIN号，将该PIN号填入Saezuri中才能使用该账号。而像Seesmic Desktop、Echofon for Mac、TweetDeck等都只要在客户端内填入用户名和密码就可以搞定。
Saezuri使用单列显示方式，跟Echofon类似，不过Saezuri在浏览用户profile和对话时，只是切换当前窗口内容，不像Echofon会在旁边弹出个小窗口。
比较不好的是，貌似Saezuri没有快捷键支持各种常见操作，全都通过快捷按钮完成。而且每次RT都需要用户选择是官方RT还是编辑后再发布，这点不太好，而且有个小问题是，如果用户设置了protected，就两种方式的RT都不可以了，而Echofon则只是屏蔽掉官方RT，在非官方RT时会弹出消息框提示该用户设置了tweet保护。个人感觉Echofon的实现更合适一点。
目前Saezuri还不支持Streaming API，可以设置每次新发推后自动刷新Timeline，在这点看来，这体验果然不如Echofon好，不过对于没用过实时更新的用户来说，其实并不太在意这个。
最后说一下，Saezuri是完全免费的，没有Echofon那样的广告，对Twitter功能的实现比较完整，如果它可以使用Streaming API，再加上那些操作快捷键，就比较完美了！
从TweetStats的每日统计可以看出，TweetDeck是除官方web外使用最多的客户端，对，没有之一。
与众多第三方客户端一样，TweetDeck也是基于Adobe AIR开发，不过说实话它并不像其他各种使用AIR开发的客户端那种拥有炫目的UI，甚至说，它在UI方面实在有点儿土。TweetDeck使用多列显示的UI，可以自定义在主界面顶部或底部出现输入框，而且会自动隐藏输入框，这点是比较赞的。而且TweetDeck不但支持Twitter服务，还支持MySpace等其他的SNS。而且TweetDeck可以为每个账号单独设置API，这点对于广大中国大陆用户来说非常有用。另外，最新的0.35.1版本已经支持Streaming API，可以在主界面底部的列按钮上弹出的tooltip可以看出当前是否使用了real time更新。TweetDeck在RT的时候可以让用户选择是使用官方retweet，还是编辑后再发布，这点设计感觉不太好，应该参考Echofon for Mac的做法，将这两个功能分开到不同的入口。TweetDeck也有自动缩短网址和恢复网址功能，以及图片上传功能。
TweetDeck最不好的一点是对中文的支持不好，在设置中选择使用国际化字体后，消息中的中文是可以正常显示的，不过像消息来源，以及查看用户profile的bio上的中文，全都显示不出来。
其次TweetDeck在主界面上安排了太多不常用元素，数一下总共有5行空间用于放置各种按钮，而这些按钮在大多数时候基本上是用不到的，这样的UI设计大大减小了正常的浏览空间。
再次，TweetDeck在添加列时，响应极其慢，点击需要新添加的列后，基本上没反应，要过不知道几分钟才会突然在主界面上显示出来，这很容易让用户误解，以为不能添加上。
最后，TweetDeck的各种操作缺少快捷键，这方面也要学习一下Echofon for Mac，它的快捷键就设计得比较方便。
总的说来，TweetDeck还是个不错的客户端，尤其是目前Streaming API似乎没有被墙，可以不设API直接使用。
Qt4.7.0发布有几天了，这个版本较4.6.x来说，最大的改动莫过于增加了Qt Quick。
Qt Quick是一套解决方案的统称，它包括一个称为declarative的framework，跟animation、state machine之类层次的东西，包括一个称为QML的声明式语言，还包括Qt Creator中辅助设计和编码的那部分。
开发人员可以通过名为QtDeclarative的C++模块，在自己的Qt程序中装入QML文件，并与之交互。QML语言通过一组丰富的QML元素，构建一棵对象树，以此来实现高度动态的可自定义的UI，它支持并实现了Qt的甚于QObject的类型系统，提供自动属性绑定，而且在语言层面实现了网络透明化。
之前一年多，我在wxWidgets程序中嵌入了Lua，并用wxLua在脚本中实现UI。相当于说，我在这方面自造了一个相当笨重且不好用的轮子。如今看来，Qt在脚本实现动态UI上的表现，就是我这几年来一直期望拥有的。不过QML并不能完全代替Qt原本的基于QWidget的UI方案，QML适用于创建大量简单的动态的UI，而QWidget则适用于创建复杂的静态UI。
从Qt4.7.0附带的几个declarative的demo看，UI效果挺炫的，在当今越来越注重外观，又越来越对开发效率有更高要求的大潮下，实在是个值得一用的方案。
我在Windows XP和Mac OS X 10.6上都试用了一下，感觉不错，至少demo中暂时没有发现什么严重问题。值得说一下的是，原来我在Mac OS X中安装的是Qt SDK，32位已经编译版本，发现有一部分demo运行并不正常，后来覆盖安装了64位已经编译的Qt libraries，发现那些原本不正常的demo全都正常了，真囧。不过就我看来，既然苹果官方都强烈建议开发64位程序，那就用64位的好了。
在前些天的Nokia World2010中，Twitter的业务开发副总Kevin Thau明确表示，Twitter不是一个社交网络（SNS），而是新闻，是内容，是信息！大言不惭地说，这也是我最近刚刚领悟到的一点。
从半年前，就一直想着自己写一个Twitter客户端，但是不得不说，现在已经有非常多优秀的Twitter客户端了，从共享到免费都有，覆盖了各种平台，那如果我自己要写客户端的话，有什么特色值得用户们抛弃现有的那些客户端来转投这里呢。在这大半年的时间里，我根据自己对SNS的认识，以及自己需求，不断调整心目中的客户端的特性需求，到现在才在心中有一个相对比较固定的框架、模型。
为什么FlipBoard会受到如此热烈的追捧，这就说明对于很大一部分人来说，使用Facebook和Twitter主要并不是为了与人交互和玩游戏，而是为了获取信息，而FlipBoard这种经过整理，同时又有美观排版的方式，很能迎合那些主要为了从网络获取信息的用户的需求。
处于Twitter中文圈中，比较容易忽视的一点是，将Twitter当成一个公共聊天室。当然这也是很大一部分人使用Twitter的目的，传统的网络聊天室的没落，使得用户们不得不将这种需求搬到其他形式的网络服务中，可以看到在各种BBS、论坛、IM群等等都有这种版聊的现象，所以在Twitter中存在这种现象也是正常而且合理的。只不过，从服务提供商的角度讲，应该可以从服务器端，甚至客户端提供这样的信息过滤、隔离的功能，用户可以方便地在两种应用模式间来回切换，想版聊就版聊，想读新闻就读新闻。除了FlipBoard，http://paper.li/也提供了类似的服务，但它目前只能说，这种模式还不错，各种细节方面还很不够。
再扯远一点说，现在很多人应该喜欢使用Google Reader这个服务，但说实话，Google Reader这个界面仍然有很大的改进空间。之前网上一直有人在号召大家使用RSS全文输出，但全文输出后有一个很大的问题是，在Google Reader中如果是全部展开的阅读方式，花费很多时间在拖动滚动条过滤无兴趣的条目上，实际上对于订阅了大量内容的人来说，很多内容只要一眼看到标题，或者其中的某张插图，就没必要看正文了，那现在Google Reader这种阅读方式就显得很落后了。而有一家第三方的Google Reader同步服务在这方面做了不少努力和改进，那就是Feedly。Feedly自己也提供经过分类的新闻内容，但对Google Reader中文用户来说，更有价值的是它的同步Google Reader的功能，可以提取出条目的标题和插图以及正文摘要，并以一定的热度排版，并连接了几家最流行的SNS服务，可以及时分享自己的条目，自从用了Feedly后，我几乎就不用Google Reader的官方界面了（喂喂，你是他们的托儿啊）。
再说回Twitter客户端，目前现在的客户端，基本上都是简单地通过Twitter API将Twitter的Tweet功能从Web搬到桌面或手机端等，几乎没有做更多的需求挖掘。简单地看过几十个完成度较高的Twitter客户端，目前只看到Seesmic Look收集了几组全球知名媒体的账号，但也仅仅是收集，没有更多的特性拓展。现在Twitter推出了新版界面，可以说是诠释了Twitter自己的发展理念，引领了客户端发展的方向──它提供的是新闻，是内容，是信息！
最后可以得出，我想要的客户端，是融合了FlipBoard、http://paper.li/和Feedly几者特色的客户端。它一方面可以向用户提供类似传统书报媒体提供给用户的视觉感观享受，另一方面则是结合网络、计算机的优势，提供大容量、快捷的信息分享功能。所以它不应该只像FlipBoard、http://paper.li/和Feedly它们一样只有一两家内容提供商，它应该是彻底开放的，允许其他内容提供商以固定的接口接入并提供特有的信息。而且它应该有一定的信息自动分类和索引能力，过滤重复或无价值信息，减少用户浪费的时间。
Tweetie for Mac是个在Mac系统上比较流行的Twitter客户端。
首先，它是个原生的Mac应用程序，而且轻便小巧。但绝大多数的Twitter该有的功能，还是有的。不过要提最重要的一点是，它目前貌似不支持List，这是一大遗憾。很多Twitter用户是比较重视并依赖List功能来组织自己感兴趣的推友的，客户端不提供支持，则很容易让用户放弃这个客户端，转头寻找其他合适的产品。虽然有这个大缺憾，似乎用它的人还是挺多的，确实其他的功能还是做得很赞的，也支持几种常见图床和URL缩短服务。它支持多账号，但不能自定义API，也不能设置代理，仍是那句话，Mac系统补上了这个缺点。它也不能让用户自定义刷新间隔，而且目前仍然使用着OAuth API，不过想来随着将来Streaming API的使用，这个问题也将不复存在。
其次，它界面美观，清爽。使用类似Echofon的单列显示界面。界面切换时，有动画效果，虽然并没有实用价值，却仍能让人觉得炫目。就我觉得，这应该也算是Mac风格，或者说iOS风格的界面吧。
最后，它是个共享软件，也有免费版，据说是加入了广告，实际上我用了也没发现哪里有广告，所以尽管它的功能足够简单，但也大致够用，要是它能支持list，并使用Streaming API，我肯定毫不犹豫地放弃Echofon，转投Tweetie门下。
