Florian’s article on how to use Vex as an editor widget has just been published in the German Eclipse Magazin 2.12. In a sample dialog Vex is used to enter Wiki text in the WYSIWYG way.

Vex is a pure SWT widget and doesn’t require any web browser. It’s an alternative to the solution FCKEditor in a browser widget which Thomas Kratz recently described in his post.

Vex is an acronym for Visual Editor for XML. With Florian’s WYSIWYG Wiki editor we have to rename Vex into Vest: Visual Editor for structured text.

Vex has moved from being a component in the WTP Incubator project to being a project on its own in Mylyn Docs. Like all other Eclipse projects Vex has its own home page: eclipse.org/vex. Our project lead is Florian Thienel, currently the 99% of Vex (only you can change this).

1.0.0 M8

Last week milestone 8 was released. If you already use Vex then you have to migrate your vex-plugin.xml files. Otherwise you should give Vex a try to edit XML files word processor like.

The next big thing is XML Schema support in addition to the good old DTDs. Already 1.0.0 M8 contains basic support for it. At the moment you have to register the XML Schema manually by editing the vex-plugin.xml file – the UI to do this is under development. So stay tuned. Vex is moving forward slowly but surely.

Issue 1: Top-most search results irrelevant

More often than not help is entered via search than via navigating the table of content. In cases where the requested information is available but cannot be found, this is often not because of none or too few search results but because of too many. For example, in the search results for console, Clear Console and Pin Console are displayed above Console View.

Maybe the ranking could be improved (see bug 356623) by taking the TOC hierarchy (in the TOC both Clear Console and Pin Console are children of Console View) and the linkage into account. Currently the link text is attributed to the topic that contains the link instead of – like in Google – the target topic. Especially, topics that contain the search expression in the See also or Related topics sections only should not be found. Another idea would be to have a kind of auto-grouping function similar to Google’s “More results from…” feature or similar to the already existing “Show result categories” function which has to be enabled manually and which works only on the book level instead of any arbitrary depth.

Issue 2: Nothing found

Stemming is applied to the words of the query, e.g. trick finds tricks or restoring finds restore (tip: to disable stemming surround query with quotes) but if you search for Runing external tool then nothing will be found. One little typo (in the query or in the documentation) and the Search Results tab is empty; no Did you mean: Running… will assist you (see bug 356624).

Wildcards (e.g. th?se finds these and those, work* finds workspace and working sets) and the not yet by Eclipse Help supported fuzzy search (e.g. thus~ finds this) extends the result set too, but only few people use or would ever use it at all. Also according to the survey, the missing Did you mean feature would be much more preferred than the already supported wildcards and the not yet supported fuzzy search.

Issue 3: Sharing (Web Application only)

Sharing a link that refers to a specific topic of http://help.eclipse.org or of another Eclipse Help based web site, so-called deep linking, is tricky because even if you navigate to a topic the web site address remains the same. To bookmark a specific topic or to share a link to a specific topic you have to copy the link of this topic in the table of contents. This problem could be solved by rewriting the hash part of the address via JavaScript (rewriting the main part of the URL is forbidden for security reasons) like Orion does (see bug 315013).

Cent 2: Thanks!

All of the survey participants and I are very satisfied with the Eclipse help system – a special thanks to Chris Goldthorpe for quickly fixing two problems that occurred with our extremely large documentation. But as you know: give them an inch and they will take a mile and the best is the enemy of the good.

(Based on an advertising from 1954)

62 Indigo projects compared to 39 Helios projects suggest that 23 projects have joined the release train. However, when taking a closer look at these numbers, one notices that it is the way of counting that has changed. While for instance EMF Compare and EMF Validation among EMF were counted as one in Helios, in Indigo these are two separate projects. Counting the old way the Indigo figures are less impressive:

Simultaneous releases compared (also as SVG)

Anyway, there is still some room for marketing: it wouldn’t be wrong to claim that Indigo consists of 79 projects in total (about a quarter of all Eclipse projects).

Irrespective of the way of counting, there are two more projects in Indigo than in Helios: 11 projects joined and 9 stepped off the train.

11 additional projects:

• Agent Modeling Platform (AMP)
• Eclipse Generation Factories (EGF)
• EMF Facet
• Graphiti
• Gyrex
• Jubula
• Maven Integration (M2E)
• ObjectTeams
• Runtime Packaging Project (RTP)
• Scout
• WindowBuilder

9 Helios projects that are not in Indigo:

• BPMN Modeler
• Buckminster
• Device Software Development Platform (DSDP) restructured
• EMF Teneo
• GMF Tooling
• Java Emitter Templates (JET)
• Mint
• Swordfish
• Test and Performance Tools Platform (TPTP) terminated

The total number of lines of code has increased by about 40%, which is due to extensive newcomers like Object Teams, WindowBuilder and Jubula and the addition of new subprojects of WTP and Mylyn.

According to Wayne and Dash there are 408 Indigo committers compared to 431 Helios committers (of a total of about 1000 Eclipse committers) who represent about 50 companies.

In my view, whichever way you count it, these are good numbers.

At startup a dialog is shown if the current application has not yet been added to the file context menu or if an application that is referenced by a menu item has been removed:

New and Noteworthy:

• Works now also in a 64-bit JRE (thanks to Ganor for the hint, to Timothy Gerard Endres for JNIRegistry and MinGW-w64 for being able to cross-compile a 64-bit DLL).
• Support for more than one menu item: helpful if you have more than one installation of Eclipse or when uninstalling an old and installing a new version of Eclipse in a different directory (see screenshot above).
• The icon of the application is shown in the menu (Windows Vista and Windows 7 only).
• Customizable to use in your RCP application: Open with MyRcpApplication (see How to customize).

Open Source does not require such warnings – doesn’t work anyway with pre-school children as I saw myself

Taste it via Marketplace client or by using following Update Site: http://openwitheclipse.sf.net/update

Thank you!  

Vex 1.0.0 M6 (an editor for XML with a word processor-like interface) has just come out. The change with the most impact might be the (temporary) removal of the multi-page editor. For a long time the multi-page editor has been marked as experimental because the synchronization between visual and textual editor page was only partially implemented: changes made in the visual editor page were propagated to the textual page, but the visual editor model was not updated after a change in the textual page. We have decided to remove it for now because we prefer quality to half finished features – but maybe also because we wanted to elicit some reactions. Even though Vex is installed, via the Marketplace Client only, about 150 times per month there are only few bug reports and practically no questions in the forum and mailing list.

More than 150 installations per month since DemoCamp Stuttgart, November 2010

The next things to come will be the long-awaited support for namespaces and XML schema, along with a better integration of DITA. So stay tuned!

Last week I newly created a splash screen for an RCP application. Since the last release main parts had been changed under the hood, and the new splash screen was supposed to make the user aware of the new technology. The splash screen was quickly done but I continued designing splash screen backgrounds. I tried – only for fun – different filters of GIMP and combining different layers. In the end I had created 14 splash screen templates:

Feel free to use them to refresh the look of your RCP application also.

PS: To avoid manually updating a version number on the splash screen, you can either implement a Splash Handler or integrate my simple Ant task DrawString in your build process.

Since 3.3 (June 2007) Eclipse has contained Apache Lucene 1.9.1, which was released in March 2006 as the search framework for the help system. Unfortunately, org.eclipse.help.base makes it impossible to update to Lucene 2.x or 3.x without breaking the API by reexporting Lucene packages and by exposing Lucene classes in an extension point. Nevertheless, in Eclipse 3.7 M3 Lucene 1.9.1 has been replaced by 2.9.1. What are the benefits? Was it worth to break the API? What do you have to know when you deliver help content?

Cheating with Prebuilt Indexes

On my two year old laptop with Eclipse Classic 3.6.1 it takes about 4 seconds to get the search results of the very first query. The major part of these 4 seconds contains the merging of the prebuilt indexes that are contained in the 5 documentation plug-ins (plugins/*.doc.*.jar) into one and storing it in the configuration area for later queries. Without these prebuilt indexes I would have to wait more than 30 seconds for the first search results. Even though this happens only once per installation, a 30-second wait is too long and this is the reason why Eclipse provides the feature of shipping help content with a prebuilt index.

While merging prebuilt indexes the progress bar shows 0%

Faster Indexing

To my surprise, in Eclipse 3.7 M3 with Lucene 2.9.1 the first query takes about 7 instead of 4 seconds. Is Eclipse Help with Lucene 2.9.1 slower than with Lucene 1.9.1? No, it isn’t. Because the version of Lucene which with the index is created must match the runtime version and because Eclipse 3.7 M3 is – probably by mistake – still shipped with Lucene 1.9.1 indexes, the prebuilt indexes are ignored. So it takes only about 7 instead of 30 seconds to create the index from scratch. Due to the Apache Lucene improvements creating an index is now more than 3 times faster than with the 5 years old Lucene 1.9.1. Without the prebuilt indexes the Eclipse Classic download size would be 2.6 MB smaller but the first query would take about 7 seconds (with Eclipse 3.6 and Lucene 1.9.1 more than 30 seconds) instead of 3 or 4 seconds with prebuilt indexes.

Testing the Limits

I also tested this with three huge help plug-ins: about 470 MB total size, more than 15,000 HTML files, and prebuilt indexes with a total size of about 20 MB. In Eclipse 3.6 (with Lucene 1.9.1) it takes about 10 seconds with and about 4.5 minutes without prebuilt indexes in contrast to Eclipse 3.7 M3 (Lucene 2.9.1) with only about less than 2 minutes without and about 8 seconds with prebuilt indexes.

Help Content for Eclipse 3.6 and 3.7

As plug-in developer you may want to support different versions of Eclipse. Especially if you have a huge help plug-in you should ship the content with both, Lucene 1.9.1 and 2.9.1, indexes. In contrast to the documentation it seems to be possible to register more than one index. Eclipse ignores indexes which were prebuilt with a different than the runtime version of Lucene. Of course, a plug-in that contains multiple indexes is always lager than a plug-in with only one or without an index but waiting too long for the search results will bother users and make some users stop using the help.

My 2.9 cents

Now, that the underlying search framework is so extremely fast, I think it would make sense not to merge the prebuilt search indexes into one anymore but to use the prebuilt indexes directly and merge the search result of all prebuilt indexes instead.

Why not increase the major version number of the org.eclipse.help.base bundle instead of sticking to 3.x only because the version number of the Eclipse distribution is 3.x which is a marketing and not a OSGi version number? Now it is possible to install bundles that require the Eclipse help bundle 3.x and that may fail at runtime. I would prefer the installation of such bundles being rejected. I think the OSGi versioning is helpful and we should not cheat it. In my view, developing a large framework like Eclipse in small steps with some (e.g. 2 or 3 years) backwards compatibility is still one of the biggest challenges in software development that has not yet been met.

If you attended this full-day DemoCamp then hopefully you stayed long enough and enjoyed the story about Vex and MeMaMeMi and how to edit XML without angle brackets. We said that Vex is shipped with built-in support for two XML formats, DITA and DocBook, but that’s not true anymore. Since Vex 1.0.0 M4, you can edit XHTML files out of the box as well. For all other XML formats Vex requires the corresponding DTD and CSS.

This autumn, a couple of Eclipse projects died. I agreed that archiving such projects makes it clear that the development has stopped. A frightening end is better than endless fright. But I also grieve for the projects which have assisted me so often. For example, TPTP, which was my choice after the Eclipse Profiler Plugin died at SourceForge, profiled a couple of my applications. I remember that I wasted a lot of time by often looking for updates for the Eclipse Profiler Plugin before I found TPTP. Maybe the CodePro Profiler recently donated by Google or MAT will step into TPTP’s shoes.

I also worry about the Visual Editor (VE) which taught me SWT and which has a similar name and similar story to Vex: VE was or is going to be reborn. But now, VE is on the verge of being cannibalised by the WindowBuilder, the second recent gift of Google. Hopefully, there will be a future for both VE and WindowsBuilder (as well as for CodePro Profiler and MAT) or – even better – a common future. Viva Ve(x)!

The conflict is about the main station which is going to be changed from a terminus to an underground through station (project name: Stuttgart 21). Unfortunately, some people found out that the new station would be less efficient, its capacity will be reduced and the costs which will be paid by the tax payers are pretty much higher than the estimated € 4.3 billion. Only those people will benefit who are going to develop the area which will not be needed anymore for the railway tracks on ground.

Activists against Stuttgart 21 are camping in tents and tree houses in the park

Of course there have been a couple of similar conflicts in Europe these times. But for me this one is different not only because Stuttgart is my home town. Communication via internet plays an important role in this conflict: For example the protesters have set up several web sites, they call for spontaneous actions in the park to protect the 300 century-old trees scheduled to be cut down by Twitter, E-Mail, and SMS. Videos recorded on mobile phones that are both live streamed and uploaded on YouTube have proven that the demonstrations were peaceful (contrary to some claims). From my point of view this new form of protest is just like Open Source: transparent, open, and powerful. It also uses the same methods to spread knowledge and to communicate.

Fence around the construction site today

So why not plan a short stop-over at Stuttgart main station and have a look at the fence (see picture above) around the construction site (but watch out for the police at the ongoing demonstration)? You might be able to boast about having been at this historic place on day.