I thought I’d write a quick blog that might help anyone using Eclipse’s Graphiti framework and want to have direct edit activate on double-click rather than the slightly awkward single click method that is used by default. It turned out to be really quite easy, but there is a small quirk, so I thought it was worth documenting here.

The first thing you need to do is set up a double click behaviour provider as per the tutorial Providing Double Click Behavior. The slightly tricky bit is figuring out how to call the direct edit feature on the double clicked element. This can be accomplished with code similar to the following:

IDirectEditingInfo directEditingInfo =
    getFeatureProvider().getDirectEditingInfo();
directEditingInfo.setMainPictogramElement(pe);
directEditingInfo.setPictogramElement(textShape);
directEditingInfo.setGraphicsAlgorithm(
    textShape.getGraphicsAlgorithm());
directEditingInfo.setActive(true);
getDiagramEditor().refresh();

Where pe is the PictogramElement containing the text to edit and textShape is the AbstractText element itself – which you get via the ICustomContext object. The IDirectEditingInfo interface doesn’t have the greatest documentation, so it’s quite possible what I’ve done here isn’t entirely correct, but it does seem to work. The real quirk is the need to call refresh for anything to happen, hopefully this will change in the future. (I’m also not clear why I need to set both the GraphicsAlgorithm and the PictogramElement, but there could be a good reason for this).

– Adrian.

Testing Eclipse plug-ins isn’t the straightforward walk-in-the-park you might be hoping for. For me it’s been a marathon in a maze full of dead-ends. In the hope that I can spare you some of my pain, here are ten hints for anyone embarking on a similar journey:

1. As you probably know, you can use “Run As” to run code as a “JUnit Plug-in Test”. This creates a new workbench instance for running the tests, which means you can use the Eclipse Platform API within your tests. You have a large degree of control over the launched workbench, including options to control exactly which plug-ins are in the workbench or to run headless. (This run method  is frequently referred to as PDE JUnit Testing if you want to search for further resources).
2. Further to the idea of controlling the test workbench, be aware of the concept of Target Platform – this allows you set up a workbench for compiling and testing against that is significantly different to your host workbench.
3. Put any PDE JUnit test code in a completely separate plug-in. This sounds like a pain as it creates yet another project in your workspace, but it is necessary to avoid your released plug-in being dependent on JUnit and/or other test resources. (You might find that you now need to export extra packages from the plug-in being tested before they can be used in the tests. I don’t think there is a way around this.)
4. If you can separate your plug-in code into separate model and view plug-ins (or perhaps a jar and a plug-in), seriously consider doing so. This means you can keep your model tests completely separate from your view tests so that changes to ephemeral things like dialogue boxes won’t break them.
5. You might find that you can use mocking libraries to isolate your code and avoid depending on components which require user interaction. Or you may well find this is far more trouble than it’s worth. (I started down this path but gave up when a supertype asked for user-confirmation with no way to turn it off).
6. PDE JUnit tests are naturally pretty slow, as they need to start and stop Eclipse. This a major problem as it decreases the frequency with which you will be willing to run them and increases the time needed to write them. (I think you could even argue that they are no longer truly “unit” tests because of this). You might be able to mitigate this by using a continuous test runner which will regularly run the tests in the background for you.
   
   
   

   Not the sort of plug-in test I'd recommend. Image courtesy of artlebedev.com.

7. You might find SWTBot is a lifesaver. It essentially provides various methods for locating UI elements and exercising them. For example, you might ask it to find the dialog box which says “Confirm Delete” and click the button titled “Yes”. There are also controls for waiting on various conditions and taking screenshots of failures. SWTGefBot also exists which has special features for getting GEF elements. Be warned however that SWTBot has a typical lack of documentation and several outstanding bugs. (I just noticed a similar UI testing tool called WindowTester Pro which looks like it might be a better choice).
8. Be aware of whether or not your tests run in the UI thread. SWTBot tests never do, but PDE JUnit tests will by default. If you are not in the UI thread, you will have to use the syncExec or asyncExec methods (either from the Eclipse Display class or the SWTBot UIThreadRunnable class) to run any code that calls the PlatformUI in Eclipse. If you do run in the UI thread, be aware that your test will hang if the editor waits for a user response.
9. Documentation on how to do plug-in testing is sparse. Some of the best resources are the tests for existing plug-ins – I’ve been looking at the tests for Graphiti, which use a range of techniques including mocking and SWTBot. If you’re using SWTBot, you will probably need to look at the source code to figure out how to use it in some cases.
10. Have a look at buckminster, a framework for automating building, testing and deploying Eclipse-based software solutions. It looks like it supports PDE JUnit Tests and SWTBot and could be potentially used for setting up a continuous integration style build/check-in process. I only recently came across this, so I haven’t had time to try it out.

Hope this list is of some help!

–Adrian.