Category Archives: Eclipse

Blog’s about Eclipse

Eclipse Commands: Cut, Copy and Paste

I came around the requirement to enable the default cut, copy and paste function as menu entries within the main menubar. When adding the commands org.eclipse.ui.edit.cut, org.eclipse.ui.edit.copy and org.eclipse.ui.edit.paste to my menubar using the org.eclipse.ui.menus extension point. Unfortunately, these menu entries where disabled all the time. This was pretty comprehensible, as there was no active handler available. So I did register an appropriate handler (working like the Eclipse WidgetMethodHandler) using the IHandlerService. It takes the currently focussed element and checks whether this Control has the necessary cut(), copy() or paste() method to invoke and calls the required method on execution. So far, so good, my menu entries were now enabled – at least sometimes?!? The reason for that was the isHandled() method of my handler which returns true only if the method is available on the currently focussed element.

/** {@inheritDoc} */
@Override
public boolean isHandled() {
return isTargetMethodAvailable(Display.getCurrent().getFocusControl());
}

As the enablement state is determined only on the context part’s (IWorkbenchPart) activation, the state is only requested once for the default focus Control of the part. So the state of the commands stays the same for the whole part activation. Additionally, a ‘no active handler available’ exception is thrown, if the menu entry is selected with a focussed Control not supporting the method. Bad luck.

So, what to do now? I ended up registering a focus Listener for all elements of the part to keep the command state in sync with the handler state.


// create a listener for tracking the focus
final Listener listener = new Listener() {
/** {@inheritDoc} */
@Override
public void handleEvent(Event event) {
ICommandService commandService = (ICommandService)workbenchPart.getSite().getService(ICommandService.class);
commandService.refreshElements(commandId, null);
}
};

The refreshElements() method calls the updateElement() method of active handlers for the given command ID implementing the IElementUpdater interface. So I let my handler implement that interface, the interface method simply fired an HandlerEvent stating that the enabled state changed.

/** {@inheritDoc} */
@Override
public void updateElement(UIElement element, Map parameters) {
fireHandlerChanged(new HandlerEvent(this, true, false));
}

The only thing left to do was to implement the isEnabled() method which is used to determine the commands enablement state.

/** {@inheritDoc} */
@Override
public boolean isEnabled() {
return isTargetMethodAvailable(Display.getCurrent().getFocusControl());
}

There you are, it works!

Model View Presenter, Passive View & DI

After three days of interesting conversations I’m off to my November holidays. This is a very calm and silent time which leaves a lot time for interesting thoughts.

Denmark

Denmark

I heard a talk about testing RCP Applications on Wednesday shortly before I left Munich which was pretty interesting. Ralf Ebert outlined a way of designing GUIs to ease testing by applying the Model View Presenter pattern in combination with the Passiv View pattern. Basicly it introduces a presenter which mediates between the ‘Model’ and the ‘View’. The model includes all data and logic, e.g. adding two numbers. The view simply displays everything. The presenter connects input and widgets and delegates calls from the UI to the model’s logic. This allows mocking the view’s behaviour and simply test the logic within the model.

The testing aspect sounds interesting, but something else comes a long with that design. In distributed systems, the view usually calls some logic from serverside services. That means, the view has to somehow access a service instance by using some context holding component. Now, what about making the view part of this service structure and provide the service via DI. Usually (in Spring terms ūüėČ ) this means hooking the view into the service container, which is pretty bad (if even possible) as they are controlled by the platform. But using a so called view model (at least I tend to call it like that) solves that. The model (and even the presenter) may be hooked easily to the container, which makes interaction quite easy.

Nice idea, what do you think?

Greetings from the W-JAX

I had my Eclipse RCP Workshop here in Munich yesterday together with Benjamin and Matthias. It was quite a nice little event with about 20 participants. As usual, we had a little introduction held by Matthias, which outlines the RCP / OSGi basics. Then we went on with the hands-on part of the Workshop. Ben introduced Views and JFace Viewers and I concluded by showing Extension and Extension Points. I hope everyone had fun, at least we three had.

Eclipse RCP Workshop

Eclipse RCP Workshop

I you did not attend the W-JAX this year, do it next year. It is a great location and a lot of interesting talks. ¬†So, see you next year ūüôā !

Eclipse RCP & Logging

Logging within an Eclipse RCP application is pretty easy, every Activator provides an¬†ILog using it’s getLog() method. Though it’s a little annoying wrapping the log statements with an IStatus, using some convenience methods solves that. But what about using another logging framework, e.g. Log4J?

Nearly everybody who tried to use Log4J accross Eclipse bundles faced the context classloader problem. Usually, the Log4J binaries should be placed within a library bundle. The configuration, the log4j.properties file, though is supposed to be somewhere else within a project specific bundle. Creating a Logger instance then runs into a problem: the configuration is not visible from the library bundle. So what to do now?

A pretty elegant solution is to use a fragment containing the configuration tied to the library bundle. So the project specific configuration is separated from the framework and can be managed individually.

Eclipse DemoCamps 2008 – Ganymede Edition/Hamburg

Yesterday, the Eclipse DemoCamp 2008 Ganymede_Edition/Hamburg was on schedule in Hamburg’s Former Coffee Exchange. Round about 40 Eclipse¬†enthusiasts took part which is a pretty nice crowd of people. Thanks to Peter and Martin Hamburg now provides two regular events for the Eclipse community around here¬†which¬†is¬†really¬†nice (assuming¬†and¬†hoping that the DemoCamp and the Stammtisch will now occur regularly :).¬†We had very interesting talks about Eclipse, especially Reginald’s talk about automated GUI Testing was pretty wicked. Unfortunatly I missed out taking photos, but trust me, if you didn’t attend, do it next time!

Hamburg & Eclipse

Awesome¬†– Beautiful location and 35 participants proved Hamburg to have a big¬†interested¬†Eclipse¬†community.¬†Thank¬†you¬†Peter¬†an¬†Ralph¬†for¬†organizing¬†this¬†event. I¬†think¬†there’ll¬†be¬†another¬†one for sure.

What¬†I¬†found¬†funny¬†is,¬†that¬†I¬†met¬†Markus¬†Kuppe, who¬†I thought lived in the same street with me when I was a little boy (about 8 years old or so). Actually he did’t, it was a friend of his. So I was wrong, but anyway we¬†had¬†a¬†pretty¬†nice¬†talk¬†about¬†OR¬†mappers¬†and¬†OO¬†DBs.

This¬†is¬†pretty exiciting¬†when¬†it¬†comes¬†to distributed¬†Eclipse¬† RCP applications – but you’ll have to wait for my book to read more ;). So here are some pictures for those who missed today – Don’t worry, there’ll be another one, pretty sure!

itemis labs kiel on talk
peter taking a picture of me taking a picture
the table

Eclipse Stammtisch Hamburg

Tomorrow, May 5th, the first “Eclipse Stammtisch Hamburg” will take place. Everyone who is interested in Eclipse is invited. So drop by for a glass of beer and some words about Eclipse. We’ll meet at 19:00 at the Bolero Bar & Restaurant in Hamburg Ottensen, don’t miss it!