Dr. Stefan Winkler
freier Softwareentwickler und IT-Berater

Today was not the first time, I made a common mistake with NatTable layers. And since it always takes a few minutes until I identify the problem, I'll post it here (as note to myself and maybe because it is helpful for anyone else ...).

The symptom is that when scrolling in a NatTable, it is not–or not only–the NatTable which is scrolling, but each cell seems to be dislocated in itself, leading to this:

NatTable messed up scrolling

The problem lies in my misinterpretation of the constructor JavaDoc of ColumnHeaderLayer (or RowHeaderLayer), which states for the second argument:

horizontalLayerDependency – The layer to link the horizontal dimension to, typically the body layer

It turns out, that I usually confuse the body data layer with the body layer. For my typical tables, the main part of the table is composed of the body data layer, the selection layer, and the viewport layer on top. 

The image shown above is usually the result of giving the body data layer as the horizontalLayerDependency parameter instead of the viewport layer (which is correct, because the viewport layer (as the topmost layer of the body layer stack) plays the role of the body layer in the sense of the ColumnHeaderLayer constructor's horizontal layer dependency).

So, should you ever encounter the above symptom, check your ColumnHeaderLayer and RowHeaderLayer constructor for the correct layer arguments.

I am currently working for a customer on an existing Eclipse RCP (based on Luna) which consists of 99% Eclipse 3.x API. The customer wants to migrate to E4 gradually, but there is no budget to migrate existing code all at once. Instead, the plan is to start using e4 with new features and migrate the other code step by step.

So, when I was given the task of creating a new view, I wanted to use the "new" (in Luna, anyways) e4view element for the org.eclipse.ui.views extension point. The good thing about this is that you can easily write JUnit tests for the new class because it is a POJO and does not have many dependencies. 

My problem is that part of the customer's RCP uses Xtext and several components or "services" (not actual services in an OSGi sense) are available via Guice.

So I was confronted with the requirement to get a dependency available via Guice injected in an E4-style view implementation:

public class MyViewPart
{
    @Inject // <- should be injected via Guice
    ISomeCustomComponent component;

    @PostConstruct // <- should be called and injected via E4 DI
    public void createView(Composite parent)
    {
        // ...
    }
}

One of my customers is still working with a Luna target platform on Windows (they have lots of divisions and need to coordinate a standard target platform among all of them, which is why the process of updating to a newer version is always a bit slow). Recently, they have switched their IDE provisioning to a custom Oomph-based setup.

As I often do remote development for them, I wanted to install the provided IDE with all the team-wide settings as well on my own laptop. So I liked the idea of taking the Oomph setup model and install the IDE with it on my Mac. But I didn’t come far. The Eclipse Installer opened (in advanced mode), the (custom) product was displayed, but I was not able to select it. The installer showed me this message:

The selected product has no versions that can be installed on this platform.

So the year 2016 has already been upon us for three weeks, and one of my resolutions is to write more blog-posts. Let’s see how this turns out…

For one of my customers, I am currently developing a GEF/Draw2D-based editor. I chose GEF 3.x instead of GEF4 for the implementation mainly for two reasons:

  1. The target platform of my client as of now is Eclipse Luna and I am unsure if I would have been able to get GEF4 to work on Luna (there are other EMF features in the target platform used by different components, so I am not very flexible with respect to versions in the EMF field)
  2. Due to its maturity, there seems to be more documentation out there for GEF 3.x than there is for GEF4. For example, I have found the Kindle version of The Eclipse Graphical Editing Framework on Amazon. While this book does not contain the answer to all obstacles I came over, it contains a lot of answers and explanations, and I can recommend it as a good reference and tutorial.

In the next few blog posts, I will point out some of these obstacles which I were not able to find a solution right away, and I hope that by writing about them, and how I solved them, I will help others to find answers to similar issues faster.

So here goes–something simple to start off:

Untyped EditPart members

Obstacle:

Well—not really an "obstacle", but I found it quite annoying that org.eclipse.gef.editparts.AbstractGraphicalEditPart returns general types for getModel(), getFigure(), and getParent().