So I looked into the multitouch API in SWT (btw. it is really to use, check snippet 353). Luckily, only a gesture listener had to be added, that is already supported by the Zest graph widget.

I thought about what gestures could be universally supported in the Zest graph, and found that scrolling is already supported, magnification is easy to implement, and for rotation I found a possible use.

Today, I finished the implementation, and created a short video presentation that shows the features in action. See the Youtube video: http://youtu.be/cVVxOIwHN7s

Additionally, it is possible to replace the built-in gestures by creating the graph with a specific style bit, and adding other gesture listeners manually as below:

//Disabling default gestures
Graph graph = new Graph(parent, ZestStyles.GESTURES_DISABLED);
//Adding own gesture listener
graph.addGestureListener(new GestureListener() {

  public void gesture(GestureEvent e) {
    switch (e.detail) {
      // Do nothing
    }
  }
});

I believe the base implementation of the gesture support is useful, but I am open to change it if someone has a better idea.

However, while using Xtext I found some minor “paper-cuts”. One of the most problematic of them was the fact that I cannot open my textual models using the Sample Reflective Ecore  Model editor, as I get an exception: java.net.MalformedURLException: unknown protocol: java.

A similar exception occurred if I tried to open the files programatically (but without the help of the generated Xtext editor). When I asked in the Eclipse forums how to open Xtext model files programatically, I was answered (btw. very quickly – kudos for that ) that a specific ResourceSet implementation is needed that refers to model files and classes available in a Java project.

This gave me the idea to create an Xtext extension that allows opening an EMF tree editor, the Xtext Reflective Tree Editor. The plug-in consists of two parts:

1. An extended version of the org.eclipse.emf.ecore.presentation.EcoreEditor class, that opens its ResourceSet using the Xtext API (more specifically, uses an injected ResourceSet);
2. And an Xtext generator fragment, that can be used to generate a new editor extension to the ui project (with the corresponding dependency added to the reflective editor plug-in).

Usage

To use the plug-in, just follow the following simple steps:

1. Add hu.cubussapiens.xtext.reflectiveeditor as a dependency to your language project.
2. Extend your editor generation workflow:
1. Import the generator package: import hu.cubussapiens.xtext.reflectiveeditor.generator.*
2. Add the new generator fragment at the end of the generator (file.extensions is the list of file extensions defined in the default workflow):
   fragment = ReflectiveXtextEditorFragment {
fileExtensions = file.extensions
}
3. Regenerate your language.
3. Unless the plugin.xml files are updated automatically, you have to copy the newly generated editor extension from the end of the plugin.xml_gen file of the ui plug-in to the plugin.xml file. The simplest way to do this is to select both files, and open the compare editor from the popup menu (Compare with/Each other…), the copy the changes manually.
4. Finally, open the runtime workbench, and open your textual model files from the popup menu using Open with/«LanguageName» Reflective Editor. The result should be similar to the screenshot below.

The Xtext Reflective Editor

In my case, the editor shows both the domain model generated from the file directly (the Pattern Model element), the inferred JVM model classes (the various JVM Generic Type instances), and also the referred Java classes as external resources (the resources beginning with the java:/ URIs).

Download

If you are interested in the plug-in in action, download it from our update site: http://eclipse.cubussapiens.hu, or take a look at the repository on Github: https://github.com/ujhelyiz/xtext-reflective

Version 0.5.3 is already available, and hopefully works well for all languages.

This year, during the OMG/Eclipse workshop a day before EclipseCon 2012 István will present our approach together with our new results:

14:35 – 15:00

High performance queries and their novel applications

István Ráth- Research Associate, BME

High-performance model queries are still a major challenge for the industry standard Eclipse Modeling Framework (EMF), they are intensively used in various model validation, model transformation or code generation scenarios. Existing EMF-based query technologies (like Eclipse OCL, EMF Model Query 1-2, or native Java programs) can have significant scalability issues for complex queries of models over 50-100000 model elements. Moreover, it is often tedious and time consuming to efficiently implement EMF-based queries manually on a case-by-case basis.

Recent initiatives, such as the EMF-IncQuery framework (http://viatra.inf.mit.bme.hu/incquery) have proposed innovative algorithms to mitigate this issue. EMF-IncQuery uses a graph query language, and provides incremental query evaluation by caching the results of the model queries and incrementally maintaining the cache when the underlying EMF model changes. Furthermore, the EMF-IncQuery framework can be easily integrated into existing EMF-based applications in a non-intrusive way.

In the first part of the talk, we overview the results of a thorough benchmark comparison
intended to aid software engineers in picking the best tool for a given purpose. The measurements involve several versions of Eclipse OCL, manually optimized Java code, dedicated academic query and well-formedness checking tools and EMF-IncQuery and highlight the most important practical considerations of queries in model-driven tool design.

In the second part of the talk, we briefly overview novel and innovative uses of high performance queries such design-space exploration, whereby traditional modeling is augmented with AI techniques to aid the (semi-automatic) optimization of model-based software designs.

If you are interested in modeling techniques, I recommend attending to the talk. As a teaser, I show now an existing application of such AI-based techniques: an automated quick fix generation for domain-specific modeling languages. We already presented this technique, albeit based on the VIATRA2 transformation framework in VL/HCC 2011. The article, together with a video demonstration is available from http://dx.doi.org/10.1109/VLHCC.2011.6070373

For interest, the video demonstration is also uploaded to Youtube for easier watching. (UPDATE: For feed readers the video url is the following: http://youtu.be/kPc4x01K7-s).

Plug-ins as model containers

Creating plug-in projects to contain models is easy with PDE: not even a single line of code is needed. The user can create a non-java plug-in project, or convert a resource project to plug-in project by clicking on ‘Configure/Convert to Plug-in projects’ in the pop-up menu of the project.

It’s finished: the user now can define dependencies between projects and even install/update third party plug-ins from update sites!

Creating cross-links

Of course, if the user wants to use the models from the dependent plug-ins we must show the contents of these models on the GUI. This step is highly domain-specific, therefore I leave it to the reader. The part of determining the visible resources from the imported plug-ins is common for all uses.

To use the dependent models, we need to load not only the directly referenced plug-ins, but the plug-ins needed by them recursively:

/**
 * Collect all plug-ins on which the given plug-in depends.
 * @param name
 * @return
 */
public static List<String> collectAllDependencies(String name){
    Set<String> all = new HashSet<String>();

    Queue>IPlugin< process = new LinkedList<IPlugin>();
    process.add(getPlugin(name));

    while(!process.isEmpty()){
        IPlugin plugin = process.poll();
        all.add(plugin.getId());
        for(IPluginImport pi : plugin.getImports()){
            String imported = pi.getId();
            if (!all.contains(imported)){
                process.add(getPlugin(imported));
            }
        }
    }

    return new ArrayList<String>(all);
}

public static IPlugin getPlugin(String name){
    IPluginModelBase mb = PluginRegistry.findModel(name);
    IPluginModel m = (IPluginModel)mb;
    return m.getPlugin();
}

When we got all plug-ins to use, we just need to collect the resources from them. In this step we must prepare for two cases: whether the plug-in is a workspace plug-in or not. A workspace plug-in is a plug-in in development. There is a project in the workspace which contain the plug-in contents. Unlike installed plug-ins which exists in the plugins directory of the eclipse installation:

public static Collection<URI> getVisibleResources(String pluginname) throws CoreException{
    IPlugin plugin = getPlugin(pluginname);
    final Collection<URI> result = new ArrayList<URI>();

    //The plugin has an underlying resource if it is a workspace plug-in
    IResource r = plugin.getPluginModel().getUnderlyingResource();
    if (r != null){
        r = r.getProject();
        r.accept(new IResourceVisitor() {

            @Override
            public boolean visit(IResource resource) throws CoreException {
                if (resource instanceof IFile){
                    result.add(URI.createPlatformResourceURI(resource.getFullPath().toString(), true));
                    return false;
                }
                return true;
            }
        });
    }else{
        Bundle b = Platform.getBundle(plugin.getId());
        Enumeration<URL> urls = b.findEntries("/", "*.e", true);
        while(urls.hasMoreElements()){
            URL url = urls.nextElement();
            URI uri = URI.createPlatformPluginURI(pluginname+url.getPath(), true);
            result.add(uri);
        }
    }

    return result;

}

As for normal eclipse plug-ins, if a workspace plug-in exists with the same name as an installed plug-in, the workspace version will be used.

Because EMF needs all resources to be loaded into one resource set to resolve crosslinks, it is advised to use some kind of indexer to reduce load times.

Special case: Xtext

If you’re using this method with Xtext, some things will become much simpler as it provides you some additional infrastructure compared to EMF. First, you won’t need to write your own indexing service as Xtext does everything for you from caching to lazy linking. Second, you can implement your own builders as builder participants, which leverages the problem of creating and configuring resource sets and loading resources.

The easiest way to use PDE functionality is to implement the possible crosslinks as scopes:

public class PluginDependencyScope extends AbstractScope {

    private final List<IEObjectDescription> descs = new ArrayList<IEObjectDescription>();

    /**
     * @param parent
     * @param ignoreCase
     */
    public PluginDependencyScope(URI context,ResourceSet resourceset, IScope parent) {
        super(parent, false);
        String projname = context.trimFragment().segment(1);
        List<String> deps = MODembedCore.collectAllDependencies(projname);

        for(String d : deps){
            try {
                for(URI uri : MODembedCore.getVisibleResources(d)){
                    try{
                        Resource r = resourceset.getResource(uri, true);
                        for(EObject eo : r.getContents()){
                            if (eo instanceof Package){
                                String name = ((Package) eo).getName();
                                QualifiedName qname = QualifiedName.create(name.split("\\."));
                                descs.add(EObjectDescription.create(qname, eo));
                            }
                        }
                    }catch(Exception e){

                    }
                }
            } catch (CoreException e) {

            }
        }
    }

    /* (non-Javadoc)
     * @see org.eclipse.xtext.scoping.impl.AbstractScope#getAllLocalElements()
     */
    @Override
    protected Iterable<IEObjectDescription> getAllLocalElements() {
        return descs;
    }

}

Problems

This does the magic, but it’s not perfect. There are some major flaws which are not easy to deal with:

• Depending on PDE pulls the entire PDE+JDT into your product even if your user does not intend to use it. This is a minor problem, it just causes overhead on the disk usage.
• PDE is defined mainly for Java Plug-in projects. The whole user interface contains items which are meaningless in our special case.
• If the user is not familiar with PDE and OSGi concepts, she/he will have a hard time understanding the user interface and the operation of cross-link resolution.
• When the user tries to add a plug-in to the dependency list, all installed plug-ins are listed, including platform, PDE, JDT, EMF and other components. It may be hard to tell which plug-in contain models of a specific domain.

Conclusion

Functionally, PDE contains everything you will need for partitioning models. If the targeted user base is experienced with eclipse, reusing PDE is an option. If needed, some isses can be worked out with some effort. For example the MANIFEST.MF editor can be replaced with a more domain-specific editor, which can filter out uninteresting plug-ins from the dependency list and include additional information which may needed by your domain.

I’m using this technique to share some common libraries to users for my own domain-specific language. It’s better than telling the user to download some files and copy them to the workspace. Let me know if you found better ways.

This year, a collegue of mine, István Ráth will attend at EclipseCon Europe, and during the Modeling Symposium present the basic use cases of the tool. In the following I attach a short abstract of the talk to give a basic idea:

EMF-IncQuery: Incremental evaluation of model queries over large EMF model

A Talk at the EclipseCon Europe 2011 Modeling Symposium
Presenter: István Ráth

High-performance model queries are still a major challenge for the industry standard Eclipse Modeling Framework (EMF), as they are intensively used in various model validation, model transformation or code generation scenarios.

Existing EMF-based query technologies (like OCL, EMF Query or native Java programs) have significant scalability issues for models over 50000 model elements. Moreover, it is often tedious and time consuming to efficiently implement EMF-based queries manually on a case-by-case basis.

This talk introduces EMF-IncQuery, a declarative and scalable EMF model query framework. EMF-IncQuery uses a graph query language, and provides incremental query evaluation by caching the results of the model queries and incrementally maintaining the cache when the underlying EMF model changes. Furthermore, the EMF-IncQuery framework can be easily integrated into existing EMF-based applications in a non-intrusive way.

During the talk, we quickly overview how easy it is to define and integrate highly scalable model queries into existing EMF-based applications, in the form of a very short live demonstration using the MDT Papyrus modeling tool. The scalability of the engine will also be demonstrated, with on-the-fly constraint revalidation that takes less than 100 milliseconds over large AUTOSAR models with over 1 million elements.

 

More info: http://viatra.inf.mit.bme.hu/incquery

Unfortunately, I cannot go to the conference, but I hope, the 10th birthday of Eclipse will be celebrated well. Have fun, and if you are interested, listen at our talk.

SourceCloud of the Debug Visualisation Project

However, it is interesting, that the strings ‘end_of_line‘ and ‘sp_cleanup‘ found their way in. Luckily, only a few one-character names and numbers are present, meaning, we managed to created longer variable names…

The cloud of the VIATRA2 model transformation framework is more interesting: it is a much larger codebase, developed for several year by around a dozen people. Because of the size I generated the cloud using 300 words, but almost no Java keywords found their way into the graph.

SourceCloud of the VIATRA2 framework

However, the mandatory comment parts did, e.g. nbsp or the names of some creators. A lot of EMF-specific keywords are also present. They are present because we have quite a large EMF metamodel that provides several hundred generated Java files.

At last, but not least I also checked the cloud of the EMF-IncQuery project. This is smaller, then the VIATRA2 project, but larger then the Debug Visualisation. Additionally, it has a shorter history, but with several key committers.

SourceCloud of the EMF-IncQuery project

My personal favorite is this diagram, as it shows a lot of nice things: e.g. four digit numbers in large quantities (magic numbers FTW) or the absolute champion string: ‘HUKfyM7ahfg‘. All of them are present in the Ecore Diagram of the defined metamodel (the meaningless string 152 times as a postfix of an identifier ). At least, I learned something about the internal model representation of GMF.

And how do your projects look like?

EMF-IncQuery provides an incrementally evaluated model query framework: as the underlying EMF model is changed, the query results are re-evaluated, and are instantly returned when needed. Queries are formulated using the pattern language of the VIATRA2 transformation system, and the Java code necessary to execute queries are generated.

In our demo application we extended the Papyrus UML editor with on-the-fly validation of well-formedness constraints. During editing we check for non-local constraints (e.g. a Behaviour must have the same number of parameters as the corresponding operation); display the results in the editor and in the problems view; we try to provide and remove these error markers without saving or manual need to start validation.

Basically, the constraint validators are generated from specially annotated VIATRA2 patterns; the generation is currently somewhat specific to the Papyrus editor, but can be extended to support most EMF-based editors easily.

A screencast of the demo is presented below. It is important to note, that the Papyrus editor was not modified in any way, and the framework generated all Java code used during validation. More details about the demo application, such as source code, tutorial slides, can be found on the homepage of the application.

(If the embedded video does not show – e.g. in a feed reader – you could watch it on on Youtube)

I have discovered a truly remarkable proof of this theorem which this margin is too small to contain.
Pierre de Fermat

During the development of editors it is often needed to display additional information next to the document, such as error markers, search results or various coverage metrics. However, it is not a good idea to hardcode the list of supported markers during development, as the best ideas will be introduced by others – who do not want to have anything to do with our editor.

Luckily, Eclipse provides a simple way to attach markers to documents without explicit support needed from the editor developer: the markers (and annotations) created by their corresponding extensions are stored independently from the document, so these additions can be made without disturbing any existing user of the files.

As I described it in my previous post about error markers, such markers can be defined creating an extension for the extension point org.eclipse.core.resources.marker, and then using the IResource.createMarker() method to create the marker instances as needed. Then using some magic it can be displayed as the yellow or red wriggly lines during the text.

Other markers (and annotations) can be created in similarly: we create our own marker type, and register an annotation type for it, and the platform manages the rest. In my case I wanted to represent a calculated set of program statements similar to the code coverage display used by the EclEmma tool: the covered statements are highlighted with the green background.

To support such a display, I created a new marker type, that is a text marker; and to make the lifecycle-management easier, I did not set it persistent. This has been reached using the following code:

<extension
    id="org.eclipse.viatra2.slicemarker"
    name="GTASM Slice"
    point="org.eclipse.core.resources.markers">
  <super
    type="org.eclipse.core.resources.textmarker">
  </super>
</extension>

The most important difference between this marker and the one defined in the previous Markers and Annotations post is that the newly defined marker is not a problem marker, but a simple text marker. This means, the created marker will not show in the Problems view (that is nice – we don’t want to display problems now), and no default annotation is created (that will need fixing).

In theory it is possible to create annotations programmatically together with the markers, but in practice it is really a bad idea. First of all, annotations are created for the document model (thus assuming an open editor and a code dependency to that document model), are never persisted, and the resulting code fails indeterministically (I once debugged a code like that, every annotation creation code ran correctly, but some annotations were missing; re-running the code re-added the missing ones, but sometimes removed others), so this idea will not work.

Luckily, the platform provides two extension points that can be used to automatically assign annotations to marker instances. To define an automatically generated annotation type for the markers, the org.eclipse.ui.editors.annotationTypes extension point is used: basically a marker and an annotation ID is stored this way.

   <extension
         point="org.eclipse.ui.editors.annotationTypes">
      <type
            markerType="org.eclipse.viatra2.slicemarker"
            name="org.eclipse.viatra2.slicemarker">
      </type>
   </extension>

To define the appearance of the created annotation the org.eclipse.ui.editors.markerAnnotationSpecification extension point can be used. In the extensions we have to specify the annotation display methods used together with color and formatting settings.

   <extension
         point="org.eclipse.ui.editors.markerAnnotationSpecification">
      <specification
            annotationType="org.eclipse.viatra2.slicemarker"
            colorPreferenceKey="org.eclipse.viatra2.slice.color"
            colorPreferenceValue="192,255,192"
            contributesToHeader="false"
            highlightPreferenceKey="org.eclipse.viatra2.slice.highlight"
            highlightPreferenceValue="true"
            includeOnPreferencePage="true"
            label="GTASM Slice Marker"
            overviewRulerPreferenceKey="org.eclipse.viatra2.slice.overview"
            overviewRulerPreferenceValue="true"
            presentationLayer="0"
            textPreferenceKey="org.eclipse.viatra2.slice.text"
            textPreferenceValue="true"
            textStylePreferenceValue="BOX"
            verticalRulerPreferenceKey="org.eclipse.viatra2.slice.ruler"
            verticalRulerPreferenceValue="true">
      </specification>
   </extension>

Even better, by assigning preference keys to the various settings the platform also offers the users the possibility to configure the annotations: the General/Editors/Text Editors/Annotations preference page will list our annotation, and allows setting its preference values. If the preference keys are unique (that is our responsibility ), then creating this extension ends our work: annotations will be generated automatically, and they will be displayed in the opened text editors.

Annotation Preferences

The marker creation process is entirely the same as the creation of error markers: a new marker is initialized using the IResource.createMarker(String markerId) method, and the IMarker.CHAR_START and IMarker.CHAR_END markers are set for positioning the markers.

An editor opened with the annotated code

Alltogether, the markers and annotations provide an easy way to extend existing editors with meta-information (e.g. execution state, dependencies, coverage, etc.), that can be used with a very little amount of Java programming. Sadly, the content assists for extensions is not that discoverable as the Java APIs, so a lot of experimenting and/or documentation reading is needed. Luckily, documentation is available for these extension points, so knowing their name will be enough for most cases.

So, lets hope, Eclipse gives us a big enough margin to contain our proo metainformation.

This release is a bugfix release only, it is avaiable from the update site or Eclipse Marketplace, and recommended for every user of the plug-in.

The first obstacle I encountered was that my MacBook’s built-in microphone is extremely noisy, so I had to record the video and audio separately, since there’s anyway a conductor track to synchronize to (so the video and audio won’t shift out of sync, there will be only temporary discrepancies), and I will attempt the recording multiple times anyway.

The next unpleasant surprise: playing a video consumes so much CPU that the fan is turned on, which is way too noisy. This was also a showstopper. I would have tried CPU throttling, but unfortunately cputhrottle didn’t work: the binary archive was corrupted, and the source couldn’t in any way compile. I almost gave up, when the LG GT540 Android smartphone I just got for this Christmas came into mind: it could serve perfectly as the video player!

This also wasn’t easy as pie, though. After downloading the video with Video DownloadHelper and copying it to the SD card, Android’s pre-bundled Media Player couldn’t open it. I found the excellent arcMedia player, which could play it, but at an impossibly slow frame rate. So I had to resize it: I chose HandBrake, and with the preset iPod conversion profile selected (320×192), the downgraded video played smoothly even in the built-in Media Player.

So I finally grabbed the phone, my Yamaha Pocketrak 2G recorder and the printed sheet music (I preferred the SATB score to the part), and dwelved into the music. (Of course, our neighbor’s dog barked into the silence at the end – I already expected that, but I managed to cut it out.)

However, replacing the audio track of the video was also hampered: iMovie ’08 can’t import the clip it recorded to a project, so I had to Google again. After another fair amount of time, I found SimpleMovieX, which suited my needs. I separated the video & audio track, added the new audio track to the video, synchronized them a bit and at last, the dubbed version was ready.

You can view the result here. I’m glad to finally be able to join a worldwide choir in this innovative social media experiment.