Feeling

自太平洋地震网络中断之后，已经很长时间都没法正常工作了，公司网络连不上Eclipse CVS，每次都要回家去取代码，bugzilla 情况好一点，还能够勉强干活。公司里的是网通出口，家里的是电信出口，看的出来关键时刻还是电信比网通来得更可靠一些。网通有一个不错的代理可以快速的访问国外网站：http://rocketproxy.net/ ， 可惜不能用于CVS ，只能够看看网页，可惜了，不过这个代理用电信的网络访问非常慢。我自己一直使用的一个代理网站：http://www.goodwaiter.com/ ，大家需要的话可以试一试。

头一次注意到，觉得狂搞笑，在游戏中才有的场景居然移植到了IDE中，不知道这是设计者的意图，还是开发者的恶搞。一般来说，设计者的Mock up都是比较严谨的，我想这是开发者自己干的好事吧，呵呵。

扩展SWT功能，实现了Windows下注册表，磁盘，CPU，内存，目录访问，网络，关机，系统特性等常用API功能。现在可以通过CVS进行访问该项目，直接下载：http://www.blogjava.net/Files/cnfree/swt-extension.zip

SWT Extension under Windows OS can be checked out through CVS now! 

User can access it from:
 
cvs -z3 -d:pserver anonymous@feeling.cvs.sourceforge.net:/cvsroot/feeling co -P org.eclipse.swt.extension  
 
Add native method: 

snapshot:

Eclipse下的开发因为是插件化的，所以一切都要尽可能的实行标准，而不是直接操作底层，就Tree来说，就需要使用TreeViewer，而不是Tree，但是使用封装后的组件往往有一些自定义的目标做不到，比如对一个TreeViewer setInput之后，因为input Model的改变，TreeViewer要对每个节点的路径进行计算，如果得到的element和原来的不一样，就会进行路径更新，放弃原有的路径。而Tree是一个多级化的组件，有折叠的状态存在，每一个TreeItem可以拥有自己的子节点。如果直接使用TreeViewer，然后想对TreeViewer的Tree直接进行操作实际上是不可能的。TreeViewer的节点是通过ContentProvider动态拿到的，所以当我们想直接操作某一个节点，比如想让它展开，或者获得它的子节点数目的时候，得到的结果都会和预期结果完全不一样，因为那个时候TreeItem的子节点并没有被自动创建。

那么如何对一个TreeViewer的TreeItem进行操作呢？通过以上的分析得知，我们首先要创建出该节点的子节点才行。TreeViewer里有一个方法：protected void createChildren(Widget widget)，该方法是用来创建TreeItem的子节点的，可以看到它是一个protected方法，不允许外界访问的。我们可以在需要用到TreeViewer的地方，自己继承TreeViewer，覆写createChildren方法，把protected改成public。然后通过这个CustromTreeViewer，就可以自由控制子节点了。凡是我们需要操作TreeItem的地方，首先createChildren(item)，然后item.setExpanded(true)或者item.getItems[]都可以正常使用了。

一般来说，当需要记录和恢复一个TreeViewer的状态的时候，这个方法就会显得非常有用处。

如果Eclipse workspace里项目过多(我的WorkSpace大概有50个项目存在吧)，很容易会发生CVS崩溃，产生各种各样的麻烦，而重启又没有什么效果，如何修复CVS崩溃呢？其实有一种很简单的方法，首先启动另外一个Eclipse加载该WorkSpace，然后Eclipse自动进行编译，完成后WorkSpace的CVS功能就已经被修复了，然后再用以前的Eclipse加载WorkSpace就一切搞定。

上个星期在Sourceforge的Feeling项目下新增加了一个org.eclipse.swt.extension子项目，意在增强SWT的本机功能。我一向是SWT的Fans，不过却很抵触大型的RCP项目，喜欢only dependent SWT。经过一个星期的努力，现在已经整合了在Win32平台下获取系统、磁盘、内存、CPU相关信息，注册表，以及系统钩子等功能，喜欢SWT的朋友可以试用。目前还没有放出一个版本，请通过sf的CVS下载代码：

cvs -d:pserver:anonymous@feeling.cvs.sourceforge.net:/cvsroot/feeling login

由于一直使用的都是Java，对Win32编程并不是非常熟悉。但局限于Java的功能，对我们有相当大的限制，IBM就屡屡向突破这个限制，因此产生了SWT。这里我重点想说的是怎么使用Win32的系统钩子。SWT里已经包含了大量的Win32函数，不过那都是局限于Eclipse的需要，如果Eclipse不需要，SWT是不予以优先考虑的。通过SWT我们很容易使用线程钩子监控自己程序的键盘鼠标事件，而且封装的很好。但是想使用系统钩子确是一件不可能的事情，先看看钩子的函数原型：

 HHOOK SetWindowsHookEx( int  idHook, HOOKPROC lpfn, HINSTANCE hMod, DWORD dwThreadId); 

idHook -- 系统钩子类型，实际上是一个int值，具体的定义请看MSDN
lpfn -- 钩子回调函数指针，当收到钩子消息时就执行这个回调函数，回调函数有3个参数，不同类型的钩子这3个参数有不同的含义，具体请看MSDN。
hMod -- DLL实例句柄（我猜是这样，我不熟悉Win32API编程），当钩子为系统钩子时这个参数是必须的，如果是单个程序或者线程使用的钩子那么可以不用这个值。
dwThreadId -- 线程ID，如果是单个程序或者线程使用的钩子这个参数是必须的。

在SWT生成的DLL中，并没有系统钩子必须用到的hMod，并不像一般的DLL有DllMain入口可以接受到DLL实例句柄。因此我们只要在JNI下的C代码里添加这个DLL实例句柄就可以完成系统钩子的功能了：

#define Dll_Export __declspec(dllexport)

HINSTANCE instance = NULL;

BOOL APIENTRY DllMain(HINSTANCE hInstance, DWORD  ul_reason_for_call, LPVOID lpReserved)
{
    instance = hInstance;
    return TRUE;
}

Dll_Export HHOOK SetHook(int hookType,HOOKPROC hookproc)
{
    return SetWindowsHookEx(hookType, hookproc, instance, NULL);
}

Dll_Export BOOL UnHook(HHOOK hook)
{
    if(hook != NULL)
        return UnhookWindowsHookEx(hook);
    else
        return 0;
}

#ifndef NO_SetSystemHook
JNIEXPORT jint JNICALL Swt_extension_NATIVE(SetSystemHook)
    (JNIEnv *env, jclass that, jint arg0, jint arg1)
{
    jint rc = 0;
    rc = (jint)SetHook(arg0, (HOOKPROC)arg1);
    return rc;
}
#endif

#ifndef NO_UnSystemHook
JNIEXPORT jboolean JNICALL Swt_extension_NATIVE(UnSystemHook)
    (JNIEnv *env, jclass that, jint arg0)
{
    jboolean rc = 0;
    rc = (jboolean)UnHook((HHOOK)arg0);
    return rc;
}
#endif

那么通过SWT来实现系统钩子有多大难度呢?各位看看代码就知道了：

Callback callback = new Callback (this, "keyHook", 3); //$NON-NLS-1$
int proc = callback.getAddress ();
hook = Extension.SetSystemHook(13, proc);

………………………………

int keyHook(int nCode,int wParam,int lParam)
{
    int Result=OS.CallNextHookEx(hook,nCode,wParam,lParam);
    ………………
    return Result;
}

很简单吧^_^

首先申明一点，这只是本人自己的体会，并不代表大多数人的观点。每种Linux都有自己的用户群，就我而言，我只喜欢Ubuntu一种。

我平日是基本上不会用到Linux的，只是有时候测试Java程序的时候才会想到Linux。最近用公司的机器跑了一下RedHat,Ubunut,SUSE三种Linux，基本结论如下：

1、第一感觉
Ubuntu：安装光盘就1张CD，下载便捷，界面非常好看，令人耳目一新。
Redhat：安装速度非常快，虽然3张CD，可是耗时却比Ubuntu还少。
SUSE：说实话，看别人的介绍挺好，自己用就感觉一无是处。10.1还好，9.2连安装界面都还有问题，我在虚拟机下居然无法图形界面安装，说内存太小，晕，最后只能用英文文本形式安装，中文乱码。

2、启动速度
Ubuntu：启动速度非常快，很快就进入了系统界面，大概因为安装的是1张CD的缘故，基本上除了需要的服务，其他的都没有开启。
Redhat：我也就安装了核心部分和KDE界面，基本上什么服务都没有开启，感觉还行，虚拟机上启动一次2分钟左右吧。
SUSE：慢就一个字，真的是很慢。也许默认安装的服务太多，不过在虚拟机下感觉卡得很厉害，鼠标挪动都很费劲。应该是很耗资源的。(我在虚拟机下给每个操作系统都分配的是768M内存，内存方面应该没有什么问题的。)

3、界面及易用性
Ubuntu：Ubuntu的界面的确非常好看，按官方的说法是：KDE要赶超苹果，Gnome要赶超Windows。易用性也非常不错，和Redhat企业版有得一拼。在命令行模式下，感觉比Redhat更好用，没有太多的权限问题。而且apt-get使用起来很便捷，方便我这类的初学者。无法使用root登录界面。
Redhat：这个使用过多次，感觉还行吧。易用性不错~
SUSE：除了别人的介绍以外，没什么印象了。

4、开发环境
Ubuntu：我用的是1CD版的，连基本的编译环境都没有，一切都要安装，到最后也没能通过，说是不能测试出编译器的版本，大概是GCC版本太高了，默认都是4.1.1的，不过我卸掉重装3.3的版本，发现依然不行，太麻烦了。
Redhat：一切都没有问题，我在Radhat下没有出现过问题。
SUSE：也没有什么问题，通过。

5、中文化以及输入法
Ubuntu：令人头疼的问题，碰到无数次错误，小企鹅输入法也apt-get不到，默认的输入法又和Firefox不兼容，晕就一个字。不过官方Wiki还是做的很不错的，美化界面后，字体很好看，和Window一样了。
Redhat：使用起来没有问题，没有专门另外处理过字体问题。
SUSE：没有试过，基本上没有在上面用到过中文。

6、自定义操作系统
Ubuntu：基本上都是自定义的，这样能够更加美观易用，挺不错的，不过最有搞wine的时候，引起系统崩溃，无法进入系统……
Redhat：不需要额外定义，简单来说，就是挺好用的，而且没有崩溃过，毕竟是企业版的Redhat ，追求稳定第一。
SUSE：弄了3次，崩溃过3次，大概它的界面系统和我有仇吧。直接放弃~~~

最后我还是选择了在Redhat上进行开发和使用，但是无法放弃Ubuntu，感觉它实在是做得很不错，小而精悍，运行速度也快。SUSE直接的让我无情抛弃，每次都崩溃，谁还敢用呀。不过怎么说呢，它们再好都还是在易用性上比Windows上差很多，命令行的方式对大多数人来说简直是摧残。Ubuntu还好一点，可以通过 apt-get remove 方式自动卸载，还有卸载管理器，不过太多的依赖项，让我对某些软件包想删取无法下手，比如那个该死的openOffice，我可是用不到那玩意的。经历了一个星期的痛苦折磨，我还是回到我的Windows世界吧。

Eclipse UI Forms without JFace and only dependents SWT. ( version: Eclipse 3.3M2 ). 
 
Modify 
Removed some parts which uses JFace and other Eclipse plugins:  
1.Package org.eclipse.ui.internal.provisional.forms  
2.Package org.eclipse.ui.forms.editor and some classes which is dependented Eclipse UI Editor..  
3.Some classes which is dependented Eclipse UI Part.  
4.Some codes which is dependented Eclipse JFace action.  
 
Moved some other plugins's classes to the UI Forms:  
1.Some Eclipse JFace Resource package classes.  
2.Some org.eclipse.equinox.common plugin classes.  
3.Some org.eclipse.core.runtime plugin classes.  
 
Replaced com.ibm.icu.text.* to java.text.*.

Snapshot

下载地址：https://sourceforge.net/project/showfiles.php?group_id=182187

连续三个月的工作终于over了，手上有了点闲暇的时间，又开始重回旧路，研究一些小玩意。这年头不缺乏技术，只缺乏创意。有技术有能力的人多的是，有创意的人却要少多了，能想到创意并实现之的人更是寥寥无几了。我就是那种最没有创意的人了，和我GF简直就是背道而驰~，大概是做技术做过头的缘故吧。

回头重新捡起SWT，至从换了工作以后就再也没有关注过，一直忙着生活上面的事情，工作上的事情都很少有让我操心的。好不容易有了点闲暇，当然不能浪费。Eclipse每个版本更新都有一些新的东西，所以总能找到好玩的东西。其实我对Eclipse最期望的地方就是它能够减少插件之间的依赖性，但偏偏它是越做越大，依赖的东西也越大越多。很奇怪的是，它还用了一些IBM或者其他公司提供的项目，是针对Java版重写的，方法都一样，只是实现机制不一样，不知道是出于什么原因，比如com.ibm.icu这个插件。

话说回来IBM还是蛮有创意的，果然是人多力量大，很多好玩的东西都是他们搞出来的，然后其他人受益，就这一点来说，我还是很欣赏IBM的。最近我的工作就是借鉴了org.eclipse.ui.views.properties.tabbed plugin的样式和架构，实现了界面架构上的多层重用，而且也美观了许多。Eclipse做到现在这个地步，包含的东西实在是太多了，还有很多好东西都需要挖掘。由于内部人员众多，代码编写水平参差不齐，糟粕与精华并存，而且因为项目越做越大，重构也越来越困难。尤其是底层业务模块，真的是十指连心，动哪一块都要付出很大的代价。

前几天Eclipse五周年生日，公司组织了一次Party，得知原来还是有那么几个 Eclipse 项目在国内开发的嘛。Eclipse现在有一个项目叫做technology，就是在收集大家的智慧，只要有好的创意，就可以加入其中，各位谁如果有兴趣，可以试试哦:-)

有创意就要去实现！

Eclipse 3.2的What's new 正式推出了“The Eclipse Tabbed Properties View”，这个东西以前就是IBM的一个内部项目，最近由于WTP的缘故给开放了出来。有的时候不得不佩服IBM的创意和能力，人多就是力量大。3.2推出了很多新的Feature，都颇有亮点。不知道IBM为这些新的Feature投入了多少人力物力。

Eclipse Tabbed Properties View实际上是对传统的PropertySheet的一个替换，在Eclipse3.2的new feature中，可以看到一个共同点，那就是界面变得花梢了，Eclipse Tabbed Properties View也是如此。Tab标签和UI-Form的结合，界面显得更加清爽。所有的Property都可以自定义编辑界面，重用性也得到了提高，另外还有完美的MVC架构。

实际上Eclipse Tabbed Properties View的代码我并不会感到陌生，我手头上的项目关于Property上的架构和它基本一致，都是Element，setInput，createContent，refresh这一套逻辑。不过这段逻辑不是我写的，不知道是是谁从IBM抄来的，当时抄的是GEF的架构，说是为了保持架构的一致，实际上非常冗余，挖了无数的坑。现在这个Tabbed Properties View走的还是一样的套路，由此可见IBM内部项目的架构应当非常一致。

Eclipse官方提供了一篇关于Tabbed Properties View的文章: http://www.eclipse.org/articles/ Article-Tabbed-Properties/tabbed_properties_view.html ，里面的介绍还算详细。我这儿只说一些它没有提到的东西。

Tabbed Properties View 的Tab以及Section都定义在Plugin.xml中，这里包含了一个依赖关系，Section依赖于input object，而Tab依赖于Section，于是当我们选中一个element的时候，系统会判断哪些Section的input object和这个element类型一致。这些Section将会被Property Page加载，每个Section都对应一个Tab，这个Tab会在Section创建之前先创建出来。当Section创建完毕之后，会进行setInput操作，将Model传给Section，最后在refresh的时候，给Section赋值。

另外一点，一个Section可以对应多个input，这样不同的input object可以采用同一个Section，提高了系统的可重用性。

不足的地方是Section的enablefor属性过于简单，对上下文支持不够，只能把上下文写在Section的逻辑里面了。