GEF/GMF editors throw exception on "Show location"

[istvanrath]

I suppose the problem is that GEF/GMF editors do not directly support revealing logical model objects:

java.lang.ClassCastException: org.eclipse.stp.bpmn.impl.ActivityImpl cannot be cast to org.eclipse.gef.EditPart
    at org.eclipse.gef.SelectionManager.setSelection(SelectionManager.java:270)
    at org.eclipse.gef.ui.parts.AbstractEditPartViewer.setSelection(AbstractEditPartViewer.java:751)
    at org.eclipse.viatra2.emf.incquery.queryexplorer.handlers.ShowLocationHandler.showLocation(ShowLocationHandler.java:50)
    at org.eclipse.viatra2.emf.incquery.queryexplorer.util.DoubleClickListener.doubleClick(DoubleClickListener.java:15)

Somehow, we would need to figure out a way to locate the appropriate editpart instance based on a logical instance model element. According to e.g. http://www.eclipse.org/forums/index.php/m/88549/, the solution should be inside the implementation of the org.eclipse.gef.ui.parts.SelectionSynchronizer class:

protected EditPart convert(EditPartViewer viewer, EditPart part) {
        Object temp = viewer.getEditPartRegistry().get(part.getModel()); // <-- this is the key!
        EditPart newPart = null;
        if (temp != null) {
            newPart = (EditPart) temp;
        }
        return newPart;
    }

I'd really be grateful for an ASAP solution to this issue.

[istvanrath]

@abelhegedus or @szabta89 maybe one of you could help?

[szabta89]

The problem is that the implementation of Show Location functionality was a bit tricky as we needed to use some ugly Reflection code. I will try to investigate how would it be possible for GMF based editors.

[istvanrath]

I think you need to extract the EditPartViewer out of the GEF/GMF editor somehow, and then the rest should be easy:

• you need to figure out the appropriate EditPart for the model object, by using viewer.getEditPartRegistry().get( modelObject )
• if the result is not null, then pass it as the selection that should be set.

[abelhegedus]

Now that we have a runtime.gmf project (the runtime part is confusing I think, since both helper classes deal with UI level quirks), we should put this extra functionality there.

@szabta89 I have a bit of time to play with this, if there's no fix on it's way already.

[ujhelyiz]

I'm also interested in the status of this, if I'm the assigned one. :D

[abelhegedus]

Heh, I'm working on it ATM!

[ujhelyiz]

About the naming: both classes are runtime classes in the sense, that they are not specific to the EMF-IncQuery tooling. If you look the user visible names, there is no mention of this runtime, but from the developer perspective this is a clearly runtime component that might be needed as end-users as well.

[abelhegedus]

Should be put into release, I can't do that at the moment, only later this evening (if Git allows it of course....)

[abelhegedus]

Successfully pushed to release, I hope hierarchical pattern registry commit does not mess anything up.

[abelhegedus]

Currently the GMF Show Location handler is active when the GMF editor is open, that means it will not work correctly with revealing.

The double-click listener uses a quite ugly hack to call the handler, it should create an execution event instead, if that's possible, so that the correct handler is called (if the editor is active).

[abelhegedus]

This works now, but we should think about a better mechanism for delegating handlers based on the editor for the selected Match!

[istvanrath]

What are the remaining tasks here?

[abelhegedus]

GMF tasks are ready, I have no idea if GEF has any remaining issues or who should work on them.

[istvanrath]

I'm closing this for now as it seems to be working with all the editors I have tried.