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