Description Stephane Begaudeau 2015-08-17 10:59:44 EDT

The bundle org.eclipse.sirius.interpreter depends on org.eclipse.sirius.common.acceleo.aql.ide to provide some preferential treatment to the MTL interpreter. The problem comes from this method: org.eclipse.sirius.common.acceleo.interpreter.SiriusContentAssistProcessor.CompletionProposalConverter.apply(ContentProposal) which is using the classes AcceleoContentProposal and AcceleoCompletionProposal.

Using the new completion proposal API, ContentProposal2, the MTL interpreter can provide almost the same behavior using the new API but one issue remain: How can we return the image of the content proposal?

Removing this dependency to switch to the new API would also have several advantages. We could have the support for the Acceleo 3 Interpreter View without having to provide the Acceleo MTL interpreter (for those who only want to use the AQL one for example) and other interpreters (AQL, feature:, service:, var:) could provide images for their completion proposals.

Yet the class ContentProposal2 cannot depend on the user interface so we could improve it to support images using one of the following solutions:

1 - Add a method returning an Object like the EMF LabelProvider

public class ContentProposal2 {
    ...

    public Object getImage() {}
}

With such a solution, the SiriusContentAssistProcessor would have to figure out what kind of Object has been returned (URI, URL, Image, ImageDescription, EMF's URI, etc) and then load the image accordingly. It is easy to create the proposal but quite complicated to process it to retrieve the image for JFace (which want an Image). We could thus add another method indicating what kind of image object is provided.

public class ContentProposal2 {
    ...

    public Object getImage() {}

    public ImageKind getImageKind() {}

    public static enum ImageKind {
        JAVA_URI, EMF_URI, JAVA_URL, JFACE_IMAGE, JFACE_IMAGE_DESCRIPTOR
    }
}

This enumeration would make it easier to process the image returned and it would let the Acceleo MTL interpreter provide an image directly quite easily without having to make the ContentProposal depends on an UI bundle. This change would not have a major impact on the Acceleo MTL interpreter.


2 - Add a method with a specific type (URI? URL?)

We could also choose a specific type and impose it to everybody. We would just a to select a specific type.

public class ContentProposal2 {
    ...

    public java.net.URI getImage() {}
}


Any opinion?