Eclipse hints, tips, and random musings

I learned a little something about accessibility today while playing with the Accessibility Tools Framework (ACTF) project’s Java Validation Componentry (Javaco).

Actually, I learned a couple of things before I learned the interesting part. First, Javaco currently works on Windows. Try as I might, Linux just isn’t supported. Lesson learned: read the documentation before spending an hour hunting down a bug that isn’t there.

Javaco goes through your user interface and determines whether or not it is valid to call it “accessible”. It looks for all kinds of things, like whether or not tooltips have been provided for fields and buttons; it also does this clever label/text association that I haven’t quite gotten my head around (a text field has to have a corresponding label).

Using Javaco is pretty easy. I selected a class that extends SWT’s Composite class, and selected “Accessibility Tools > Perform Validation” from the context menu. The result looks something like this:

My first error threw me for a loop: it told me that my composite was “Missing Accessible Name”. “No problem”, I thought, “I’ll just have to set that.” After a few minutes of fruitless searching, I determined that there was no method that reads anything like setAccessibleName anywhere in the SWT Text widget’s hierarchy. I was stumped. After regrouping, I came across the getAccessible() method. With a little help from the javadoc, and the SWT snippets page, I was back in business.

The Accessible Name for a widget is text that can be spoken by an accessible computer to help a user navigate through a form. You don’t actually set any value; you have to tell the widget how to respond to a request for it. Code along these lines does the job:

this.getAccessible().addAccessibleListener(new AccessibleAdapter() {
	public void getName(AccessibleEvent e) {
		e.result = "Enter personal information on this form.";
	}
});

You can (and in some cases are required to) set other values, including keyboard navigation equivalents on push buttons using the listener.

Javaco found a bunch of other problems, such as some missing tooltips (which I believe the accessibility software uses for the accessible name when available). I’m still pretty new at this, so I’m sure that there’s much more that it can (and will) expose as I play with it some more.

Javaco adds several new views to the workbench, including the “Rendered GUI” view (shown bottom left above) that manifests the composite you’re testing. The view is live and you can interact with it. It’s pretty cool: whenever you save the code, the Rendered GUI view gets updated. This is pretty handy all by itself (you can test your composite as you’re building it without have to explicitly test). The “Validation Report” view (shown bottom right above) summarizes the results of validation. The “Rulebase Viewer” view provides an overview of the rules that the validator uses and seems to have the ability to extend the set of rules.

If you’re building applications that need to be accessible, then you need to spend a little time with ACTF.

Dwight Deugo and I have been relatively quietly pounding away on a new “Eclipse IDE for Education” component in the SOC project (though I did blog about this a few posts back). The idea is to try and reduce some of the complexity faced by first time users of Eclipse who are in the process of being overwhelmed with classwork.

So far, most of the work has been on just getting things started. First, Dwight created the “JavaLite” environment which includes a new perspective, new view, and a couple of wizards that streamline the development process a bit. I’ve been spending a lot of time (too much, really) getting those pieces that we do have to build into a coherent update site and a downloadable package. In the process, I’ve come up with a few ideas about a common build infrastructure, but that’s a story for later…

I’ve been testing the Windows and Linux versions. Unfortunately, I don’t have access to a Mac, so I can only hope that I didn’t screw that package up. Here’s a screen shot.

I think that we’ve managed a reasonable first cut, but there’s a lot more to do. For starters, I don’t like the name “JavaLite” (sorry Dwight); I prefer something more along the lines of “Assignment Explorer” (but I’m still not happy with that). Your comments are welcome on bug 244644. I’m also convinced that we can do more than just strip down the existing wizards; I think there’s a better paradigm and am looking forward to experimenting with this a bit. In the meantime, I’ve opened a bunch of other feature requests and bugs if you’re looking for something to do…

Dwight’s going to unleash this on his unsuspecting first-year students this term (he’s a professor at Carleton University). We’re going to carefully monitor their use of the environment and drive their feedback into evolving the IDE.

More information about the component, including download instructions are available on the component’s wiki page.

It’s official. I am the new PMC Lead for the Technology Project. It’s all about the power. All must kneel before Zod. Actually… it’s all about responsibility. That, and the power to crush your enemies. Can you tell that I’m of two minds?

As a few of you are already aware, I’ve started a process of going through the many projects that fall under the Technology Top-level project. I’m reviewing these projects for a couple of reasons: first, I need to know more about what they do, why they exist, and where they are going. I want to be able to effectively tell people about these projects. Second, I want to make sure that these projects are doing the right sorts of things to set themselves up for success.

I’ve decided to go through them alphabetically, so ACTF and Albireo have been the first to suffer my wrath benefit from some gentle prodding (Voice Tools Project, feel free to start without me). I’ve been looking the projects over with an eye for liveliness. Active participation by project committers is certainly a part of that, but I’m more interested in the community being developed around the project. At Eclipse, the community is king.

I’m looking for a few things:

Is the project’s information complete and up-to-date? Does the project’s web page contain enough information that readers have a fighting chance of understanding what the project is all about and what it provides? Is the content grammatically and technically correct? Is the project-info page complete? Is there a project plan? Is it easy to find? An important part of developing a community is making the barrier for entry as low as possible; making your web presence as complete and correct as possible goes a long way in this regard.

How big/active is the community? This is difficult to quantify, but you can get a general feeling by looking at the activity on the newsgroups and mailing lists. Are the project’s committers engaging with their community on their newsgroup(s) (i.e. are they answering questions in a timely manner)? I look at the Bugzilla records: are folks other than the project committers raising bugs? I also look at download statistics.

FWIW, all projects should have at least one member monitor eclipse.newcomer.

How does the project define their community? Developing a community is easier if you know who your target audience is.

How is the project engaging the community? Does the project have at least one member blogging regularly? Is that blog aggregated on Planet Eclipse? Is it aggregated elsewhere? What conferences are project committers speaking at? What other forums are being used?

I’m approaching this in a how-can-I-help-you-help-yourself manner. The fact of the matter is that I don’t have any real sticks that I can use in this role. Despite what some of you may have heard to the contrary, I don’t generally like using sticks anyway (I’m more into the empty-hand thing). I hope that you all agree, that developing that all-important community is important and that we can work together to make it happen.

We have what has been referred to as an “embarrassment of riches” in Eclipse Corner. We have a lot of articles that are either in development, or are ready for publishing. The problem is that we have a bit of a shortage of reviewers and editors. Perhaps one of the problems is that we do not formally recognise the role of reviewer and editor in the process. I’d like to fix that.

A reviewer needs to be an expert in the subject area of the article. Ideally, reviewers are Eclipse committers (but I don’t think that this is an absolute necessity). The reviewer’s job is to make sure that the content of the article is technically correct. Very often, an article crosses the boundaries between Eclipse projects and so more than one reviewer may be required (i.e. one for each project referenced by the article). When the author and reviewer are done iterating over the content, an editor steps in and puts the final touches on the article. An editor is familiar with the subject area, but need not necessarily be an expert in the field (frankly, it’s great when an editor learns something in the process of editing an article). Editors need to have decent English-language spelling and grammar skills.

Do you have what it takes to be a reviewer or editor? It’s easy to do, just take a look at the bugs open against “Articles” in Eclipse Bugzilla, find an article that interests you, add a comment to the effect of “I’d like to [review | edit] this article”, and then immerse yourself in the role.

While I do relish the prospect of formalizing the role of reviewer and editor, I don’t want to formalize the process too much. Read over what the author has written so far, and provide your feedback as comments via the bug system. If you have any questions about the process, or just want to get your opinions registered about this, please add them to Bug 243486.

To make things more interesting for you, reviewers and editors will now get swag as well. You’ll also get explicit credit for your efforts. And the gratitude of a community.

The SWT Graph Source Forge project provides some pretty sophisticated interactive graphical technology for Eclipse RCP-based applications. The sample images shown on the examples page are pretty cool, but the description of the underlying technology seems even cooler. Layered canvases are a natural and very powerful extension to SWT.

It’s licensed under the LGPL. Make sure you review that license carefully!

Ingress CAFÉ (Consolidated Application Foundation for Eclipse) was selected as the Best Application Development Tool at LinuxWorld Conference & Expo this week. Congratulations!

Dmitry Leskov introduced me to Excelsior JET at JavaOne this year.

Excelsior JET 6.5 will enable you to compile your Eclipse RCP application to a native code executable and distribute it without the original class/jar files.

My first question, when Dmitry showed me JET in action was whether or not it supports the OSGi dynamic runtime. The answer is yes (which is reflected in the FAQ): even with your RCP application compiled using JET, you can still dynamically install and load OSGi bundles at runtime.

The first beta of Excelsior JET, supporting Linux and Windows, is available now. I’ve only just started playing with the Linux version, but it looks promising.

I’ve got some numbers from from the usage data collector for the month of July. It’s the first full month of real data. Currently, I’ve only got data for commands, views, editors, and perspectives used; the information is restricted to only show those entries that start with “org.eclipse.”. You can change the sort order of the table by clicking in the columns.

I haven’t been able to update the “project proximity” report. There’s just too much data for the query I’m running. Once I optimize the query, I’ll update that report too.

I generally enjoy reading Jeff Atwood’s Coding Horror blog. Yesterday his post, Quantity Always Trumps Quality, made me think of two things. First, the thoughts conveyed are exemplified at Eclipse: we value code over specifications; code is written, mistakes are made, lessons are learned, and everything gets better in the process. Second, it made me think if advice I give new grads and new hires: write lots of code.

Mistakes are okay so long as you learn from them. Oh… and be careful what you decide is API, you may have to live with it for a long time.

I blogged a while back about the potential use of a bus for delivering property change notifications in place of the very common observer pattern. A reader commented that the exact service I need to implement that sort of thing is already available in the form of the OSGi Event Service. An implementation of this service is provided by the Equinox project.

I’ve updated part of the Eclipse Expense Expense Reporting Tool example to make use of the service.

I updated my business domain objects to post events detailing their changes through the EventAdmin service. This was made relatively easy owing to the fact that I had already implemented those objects with a common superclass. I added the postEvent(…) method to that common superclass:

	void postEvent(String propertyName, Object oldValue, Object newValue) {
		EventAdmin eventAdmin = getEventAdmin();
		if (eventAdmin == null) return;

		Properties properties = new Properties();
		properties.put(SOURCE, this);
		properties.put(SOURCE_TYPE, this.getClass().getName());
		properties.put(PROPERTY_NAME, propertyName);
		if (oldValue != null) properties.put(OLD_VALUE, oldValue);
		if (newValue != null) properties.put(NEW_VALUE, newValue);

		eventAdmin.postEvent(new Event(PROPERTY_CHANGE_TOPIC, properties));
	}

It’s pretty straightforward. The first thing it tries to do is obtain the service. The getEventAdmin() method uses the bundle activator (and a ServiceTracker) to find a service that implements EventAdmin. If no such service can be found, we bail out and pretend that nothing happened. If we do find an EventAdmin, we create and post an Event instance. The postEvent method posts the event to be delivered asynchronously; the sendEvent method delivers the event to waiting handlers before returning.

The Event instance is packed with properties. The nature of these properties are application-specific. In this case, I’m including properties that tell me what has changed and in what object. The event also has a "topic". The topic is used to determine how the event is delivered; only event handlers that are listening for this particular topic will be informed of the event (there’s a little more to it than this). It’s very much like the Java Messaging Service (JMS).

This is only part of the story. Publishing events through the event service is only interesting if there are subscribers on the other side. I’ll talk about what I’ve done on that side sometime next week…