Darker Theme 1.1: CSS Selector and OSGI Weaving

I am proud to announce Darker theme plugin 1.1 [1] for Eclipse 4.x platform. The reasons to be proud are two:

1. It gets 32 stars! As a one-day amateur work, I originally just try to experience and show the Eclipse 4 good stuffs[2]. But the community pushes the project forward. I decide to maintain the project constantly until we can get one better theme in the Eclipse itself of some time.
   
2. One weaving facility has been added into the Darker. The Darker is the first/only theme plugin to get over some styling defects shipped with the standard Eclipse instance. With this on the Darker, I can announce that it can do almost anything to challenge IDEA all round on the aesthetics of dark UI! (However, I truely have no time to make this done^_^)

To update minor version, Of course, it not only contains several bug fixings, but also introduces new things. One thing is,

• CSS selector.

The is an old pearl of e4/CSS works. But I am aware of its power until Lars[4]' pointing out in one issue[5]. In fact, the Eclipse 4 makes a hard work to provide one full CSS-spec-conformant styling engine.(At least, they want it to be full^_^) The CSS properties is just one aspect of CSS spec. The full story should includes the CSS selector. The CSS selector syntax provides a very powerful way to pick up some elements/objects to apply your style with.

Like Lars suggest "styling the Quick Access box"[5], this styling could be done by this following piece[7]:

Here, #SearchField Text is a traditional descendant selector syntax in CSS[8], which picks up the Text widget on the widget with ID #SearchField.

Simple and neat!

If you want to dig a little more, the Eclipse's wiki here[9] and the old Kai tutorial(in the bottom of that wiki page)[10] may be useful. The CSS styling engine gives more fun to Eclipse UI developers, although I am afraid that the layout problems seemly show barriers mentioned in that wike page in the meantime:)

The another new is just as I mentioned above,

• OSGI Weaving.

This weaving facility use the OSGI weaving functionality introduced in OSGI R4.3[6]. It allows load-time bytecode weaving, which can grant your some AOP capacities without huge dependencies.

It is a must. Because the investigation into another request[15] shows the SWT CLabel, as the background widget of stateline, forces a fixed OS related widget color as its foreground color from Control. That is, the CSS property setting is dumb here. Obvoiusly, the problem is systematic and  it can not be fixed in a near future of Eclipse development(or maybe never). I will feel very unhappy and stupid if I say to our guies that like "please wait, I have filed a bug entry against Eclipse". Then, the OSGI weaving comes to help.

Maybe you have known Equinox weaving[11] or AspectJ[12]. Yes, the OSGI weaving is a simplified version of Equinox weaving(but note that they are still different codes). AspectJ is an big animial. I have bitter memories about the AspectJ in my Scala IDE journey[13]:) One big headache is, that the Scala IDE users regularly report some update or functionality does not take effect in their environment. One reason is just due to the weaving configuration file have not been updated or picked up successfully by their Eclipse instances. I hope Iulian Dragos(leader of Scala IDE, Typesafe) has solved this problem:)

For one little theme plugin, I definitely do not want to take the nigtmare to the users. As a developer, we should be cautious to any addition. Then, the OSGI weaving is my choice.  The detail of implementation needs some ASM bytecode generation knowledge and provides the context based weaving(like cflow pointcut in AspectJ). To be honest, AspectJ syntax is simpler than direct bytecode manipulation if you have much complex context/condition combinations. I am just preparing a game-changing AOP kind of tool, but it needs time to come to the world:)

With correct weaving to SWT CLabel, Darker get a right white text color for the dark status line.


One tricky part I just to point out here, is the starting sequence of the plugins. The weave-working plugin should takes effect before the Eclipse UI things, more detailly here SWT CLabel, loaded into runtime. If you define this logics in your UI plugin, the order is definitly wrong. I solve this problem with two
simple points:

• separate the UI and weaving(non-UI) logics into different bundles;

• start the weaving bundle immediately after framework started.

The interesting thing is I use another new R4.3 "Start Level" API[4].(The other way may be to use kinds of hook[14], but I think it is just overkill.) It avoids any forced configuration modification for users in the Eclipse. It is a good practice.

OK, after this update, I plan to fully focus on my wonderful backend stuffs in my hobby time.
Stay tuned!


[1]:  https://github.com/jinmingjian/eclipse.themes.darker
[2]:  http://jmj-eclipse.blogspot.jp/2012/12/practices-for-eclipse-4-programming.html
[3]:  http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/hook/weaving/WeavingHook.html
[4]:  http://www.vogella.com
[5]:  https://github.com/jinmingjian/eclipse.themes.darker/issues/14
[6]:  http://wiki.osgi.org/wiki/Release_4.3
[7]:  https://gist.github.com/jinmingjian/5546115
[8]:  http://www.w3.org/TR/CSS21/selector.html#descendant-selectors
[9]:  http://wiki.eclipse.org/Eclipse4/RCP/CSS
[10]: http://www.toedter.com/blog/?p=477
[11]: http://eclipse.org/equinox/weaving
[12]: http://www.eclipse.org/aspectj
[13]: http://www.scala-lang.org/gsoc2010
[14]: http://wiki.eclipse.org/Adaptor_Hooks
[15]: https://github.com/jinmingjian/eclipse.themes.darker/issues/11

Phoneme advanced and eSWT Running Under x86 Windows

Phoneme advanced and eSWT Running Under x86 Windows

Recently I still try to find interesting things to explore freely. One thing is that I mention I'd like to contribute the Eclipse in some projects, like e4 language or VE(I avoid contributing to the projects full of employees). However, the feedbacks seem not active. In my view, the reason that Eclipse is the current Eclipse is just the gigantic, passionate, dream-filled community.

Oh, come to the right topic.

There are many research JVMs under the linux. All of them are much not friendly to Windows users(the fact is that almost of them even do not consider the problem of porting to Windows). Although the linux environment is better for some programmers, it is very dangerous to think only from the programmer's perspective as a programmer. This behavior could kill your community. 

"Phoneme advanced" is one CDC target Java platform(JavaME, academically. And, I will call the "Phoneme advanced" JVM as "CVM" as follow), which is opensourced from Sun's product(after the OpenJDK borning) under the GPLv2. 

The attractive thing for me is that CVM could be seen as the compact version of J2SE 1.4(yes, that is, CVM fully complies with the JVM Specification, 2rd). That is, we can do many useful things on it.

It is easy to get the source of Phoneme. However, like all other research VMs, the build system of Phoneme is based on the sh/make of Linux. This is not easy to Windows users. To find , We need Cygwin, which provide a linux-like enirvonment for Windows. A little inconvenience for Cygwin is that it needs to be installed via internet connection. 

The good news is that the phoneme adv. provide make files for win32-x86 platform and VC build toolchain. The bad news is that the the default building scripts are not fully matched with your actual options. If your VC or SDK was installed into non-default directory, you need to carefully examine the output infos to find what the enirvoment variables are wrong and you should redefine those variable. Two detail clues here, 

1. the path for Windows is not valid for Cygwin, modify it like c:\xxx -> /cygdrive/c/xxx

2. for the Vs8 build script, the variable "PLATFORM_SDK_DIR" can not be overrided(a bug?). You should modify it by hand.

After more or less tweaking, I get the CVM into running successfully, Cool! The coolest thing is not that the CVM could be run, but that the packed size of the runnable CVM with the foundation runtime library is just about 1.1MB.  

The next big is the capability of UI application for cvm. One thing here is, you need to rebuild the native codes against with CVM' JNI headers. Don't try to use existed native library directly. Firstly, I test the SWT. But I get errors when compiling the sources under VC++2005EE and MS Platform SDK. Error logs like as follow,

...

...\MicrosoftSDK\Include\exdisp.h(39) : error C2061: syntax error : identifie

r 'IWebBrowser'

...\MicrosoftSDK\Include\exdisp.h(39) : error C2059: syntax error : ';' 

...

I can not figure out how to solve this problem. If you know, please let me know:)

Then, I remember the eRCP again. In my eye, it's a lightweight RCP implementation even for desktop. The eSWT is the base of eRCP. I fetch the eSWT sources. But frankly, bugs in the eSWT win32 codes is not rare. I have some years not to touch the C/C++ codes.Otherwise, this is a good chance for me to play with JNI deeply. After a while, I get them compiled successfully again. Cong! 

 

The above sreenshot is a sample code shipped with VE, called "SimpleSWTTextEditor". I do a little modifications to the text to test UI(JNI) and Unicode support of CVM. As you say, the basic aspect of UI is nice. However, the text of widgets has been append unreadable characters.

After intensively debugging, I find the problem exists in the #GetStringChars() method. This method return the jchar* which is called by #convertToNativeString, however this implementation in CVM seem has a non-standard behavior. (I am not sure to open this bug to eswt? or cvm?). Then after fixing this problem, I get the nearly perfect solution. The Unicode support is nice for both English and Chinese.

 

Cong! You can dream the next story...