Alle Beiträge von Marco

Executive Partner @ MEDEVIT OG Research Assistant @ FHV

Synchronising stateful items … [part1]

I’ve been banging my head some time now (which can be seen in Bug 397249) on the problem of sychronizing stateful Eclipse 4 application model items with the code.

Wait, let me set the scene first: The Items I am talking about are either Direct or Handled, Menu or Tool, Items added to either a Menu or a Toolbar in the application model. And by stateful I mean the requirements of Items of type Check or Radio to have their state synchronized with the state of the application.

Statefullness requires a Command connection

Overall stateful usage of items is bound to being connected with a Command, hence all items of type Direct are generally not considered for stateful usage. They should be used with check type only, for one shot execution of whatever you might deem necessary.

I, however, see a feasible way to use them in Type.Check which might be handy to you. In order to update the state of a Type.CHECK Direct*Item, simply use the @CanExecute annotation for a method in your contribution_uri class like this:

@CanExecute
public boolean canExecute(MItem element) {
  element.setSelected(false);
  return true;
}

@CanExecute is called everytime your element is to be shown. It allows you to update the availability of your action according to your settings, and you may also use it to update the state.

Using Direct*Items is good for smaller tasks, but one must not forget, that using this element the model has to access the implementing class to query the state. This may lead to lazy plug-ins being started just to gather the information about the availability resp. state.

Stateful Handled*Item

In order to use Handled*Items, a method (not in the code meaning but literal) is required to initialize the state of your Type.CHECK and Type.RADIO items at startup to the state of your code.

Let’s consider this for both Type.CHECK and Type.RADIO. Lets fix an example of a viewer (yes, just like this SWT TableViewer example) showing a set of Persons being either male or female. A person may also be married, single or widowed.

The Type.CHECK items in the filter will be the boolean representation of showOnlyMale in Handler, which sets it into the state to show only male persons.

The Type.RADIO items will allow us to show married, single or all persons. Here we have three contribution items which together form a radio group.

It is important that the items allowing us to select the states will be present more than once but connected to the same command. The following image depicts this:

filterCommand

The code is implemented in the Handler part, while the model is being represented by all none code parts, that is the Command and the multiple ContributionItems.

One may set the isSelected feature of the Contribution items within the application model, they are, however, not being synced to the state of the Handler (i.e. the Filter in our example) and vice versa (how should they, Eclipse does not know about the connection).

So first the question arises, whether the model should synchronize to the code, or the code to the model for this cases?

Dynamic menu contributions

Bug 389063 introduced dynamic menu items within the Eclipse 4 application model. Today Paul Webster pushed the commit to platform.ui so it is ready to show starting with tonights integration build or the upcoming Kepler M4.

But what is it, and how to use it? During development I started a sample project on called at.descher.eclipse.bug389063 that is the first to take usage of the new feature. It is accessible on my github repository.

Generally, dynamic menu contributions are added to a menu just like other elements of the form HandledMenuItem or DirectMenuItem. But instead of representing only one element they can be instantiated dynamically by anything your code wants it to show. This is similar to the dynamic menu contribution one could add in Eclipse 3.x using the org.eclipse.ui.menus extension point.

Corresponding to the Eclipse application model you now have to insert a respective menu:DynamicMenuContribution element, an example is shown in the following code snippet:

<children xsi:type="menu:DynamicMenuContribution"
       xmi:id="_JTeEkAp4EeK8ULSwuUCzow" elementId="at.descher.dmc.0"
       label="irrelevantLabelWillNotBeShown"
       contributionURI="bundleclass://at.descher.eclipse.bug389063/
        at.descher.eclipse.bug389063.dynamic.DynamicMainMenuContribution" />
 

Here one can see the reference to the contributionURI which is the class responsible to provide the Dynamic Menu Elements. There are two new annotations available which are evaluated within such contribution classes:

  • @AboutToShow the method carrying this annotation is called when the menu is about to open
  • @AboutToHide the method carrying this annotation is called when the menu is about to close

In order to provide an example I take an excerpt of the respective methods from the class DynamicMainMenuContribution class:

@AboutToShow
public void aboutToShow(List<MMenuElement> items) {
 MDirectMenuItem dynamicItem = MMenuFactory.INSTANCE
   .createDirectMenuItem();
  dynamicItem.setLabel("Dynamic Menu Item (" + new Date() + ")");
  dynamicItem
    .setContributorURI("platform:/plugin/at.descher.eclipse.bug389063");
  dynamicItem
    .setContributionURI("bundleclass://at.descher.eclipse.bug389063/
         at.descher.eclipse.bug389063.dynamic.DirectMenuItemAHandler");
items.add(dynamicItem);

In @AboutToShow an empty list, namely items gets injected. It is to be populated by the developer. The above example shows the addition of a simple MDirectMenuItem which is handled by the DirectMenuItemAHandler class.

Caution Do not put code with a long execution time within this method, as this directly blocks the opening process of the menu, and may look to the user as though the system crashed.

Providing an @AboutToHide method is optional, if one wants to say so, if however one has a reason to use it, the framework takes care about injecting the list populated during @AboutToShow into this method. So the following example shows that the list is not empty, and uses the @AboutToHide annotated method to simply increase a counter.

@AboutToHide
public void aboutToHide(List<MMenuElement> items) {
 System.out.println("aboutToHide() items-size: " + items.size());
 addSecond = !addSecond;
}

There does not yet exist support for the Application Model Editor, but I am working on it. As soon as there is news, I’ll present it here :)

Remark Recently I found out about two problems using this dynamic contribution, I already filed the respective Eclipse Bugs in 398866 and 398865.

[388402] SWT OS X List bug

Null Pointer ExceptionDuring several innacuretaly determinable situations we had sudden crashes of Elexis during work. These however were only occuring on OS X.

After some research I found out that the bug is caused by a NPE in the SWT List element every time one removed the last element of the list. I filed a respective bug on the Eclipse Bugtracker

Now I found the reason for this stuff to happen and it is entirely due to the MouseDown on the MenuItem entry not being followed by a MouseUp event. If you are interested in a sample application to demostrate the bug take a look at https://github.com/col-panic/generic-stuff

The bug was finally tracked down, and a patch was created according to my findings from Silenio Quarti – NICE!