Workbench Model Tooling

While traveling by train to Vienna and back I had time to invest some time into the workbench tooling and I think I added some nice and helpful things.

  • “Live” Model Inspection:

    The first and most important feature is that you can now inspect the model of your running workbench by hitting CTRL+SHIFT+I
  • Better support for Window-MainMenu and Part-ToolBar
  • Adding Support for Fragment-Tooling

The tooling is not as good as I had hoped to be at this point (e.g. taking part in renaming actions is not supported and I doubt to get this ready for the July release). I’ll try to invest some more time into this but I need to feedback from people to find problems and missing features, … .
I can’t guarantee to implement all of them but your input is crucial to at least fix the most important parts.

Vienna DemoCamp

I managed to get to Vienna Helios DemoCamp which took places yesterday (June 25th 2010). There’ve been some very interesting presentations about different Eclipse Projects (EMFStore and EMFCP, Object Teams, redView, …).

I gave a presentation at around 23:00 (it was my first talk with a beer next to me:-) in the night about the e4/4.0 SDK but the interest in the topic was so huge that instead of talking for 15 minutes it finally lasted about an hour. I always appreciate that when you start explaining people the ideas, the problems we are having in the current codebase they start to understand why we think we need a new revised platform.

Part of my demostration has been:

  • Demoing the 4.0 SDK RC0 (i used to write a small e4-RCP-Application)
  • Demoing our Model-Application-Tooling which can be used at development time and lately also at runtime to inspect your running Workbench-Instance and modify it on the fly (a dedicated post about the news on the Workbench-Model-Tooling will follow later)
  • I showed of our DI-Programming-Model by turning a Stand-alone SWT-Dialog into a Part-Showing up in a RCP-Application

The slides can be obtained from here and the example code I used from here (initial, solution).

Thanks to the organizer (Michael Clay and Peter Kofler) putting together once more such a fantastic event. See you next time at the DemoCamp in Vienna.

News from the Nebula

I’ve planned to write up a blog post up new cool Nebula-Features since some time but failed because of time constraints (e4 has been my main focus).

Any ways there’s not only cool stuff happening at e4. So this blog post is dedicated to new widgets and new features that got integrated in the Nebula-Sources.

New widgets finding their way to Nebula

  • TableCombo and TableComboViewer
    Did you every wanted to display icons in your ComboViewer or multiple Columns? CCombo is not able to do this because it uses a SWT-List-Widget. Nebula comes to rescue in a way that it provides you the a CCombo variant which uses a Table-Control.
  • RadioGroup-Widget with a JFaceViewer integration
    The RadioGroup-Widget and it’s viewer applies the Control-Item-concept you know to a widget built out of SWT-Buttons with SWT.RADIO-Style naturally it provides you with a JFace-Viewer integration (e.g. very handy in case of Eclipse-Databinding scenarios)

Widget which got new features

  • Grid
    One of the coolest things we introduce into Grid is the possibility to span not only columns but also rows like you know it from other grid-controls.

    Beside that we fixed some bugs. I think the important thing when saying we is that all those things have been coming from the community! Thank you very much!
  • PGroup
    In PGroup I’ve integrated myself the feature of adding ToolItems into the Header section. The API provided is very similar to the one you know from ToolItem so you are able to create items of type SWT.PUSH, SWT.CHECK, SWT.RADIO and SWT.CASCADE.

    I’d like to thank Ubiquiti Networks, Inc. sponsoring the work and contributing it back to Nebula.

Proposed Widgets

The proposal of widgets is not decreasing but we have some cool new stuff proposed for integration:

Alpha Status, Release, …

I know that this is a really pressing issue and holding of many people from useing Nebula. As stated often before many of the controls have stable API and are more or less bug free (at least there are no major problems known for them) but there are also widgets lurking around, waiting for maintainers and are not in a consumeable state.

It’s impossible for me as a project lead to step up at all the fronts and taking over the maintance (I already did this for PShelf, PGroup and Grid).

All those duties keep me away from doing the project management where the most pressing issue is to restructure Nebula into 2 projects: One for incubating widgets and one for stable widgets ready for a 1.0 release.

Please keep that in mind when you come to Nebula. We are not backed by any commercial vendor beside the rare occurences where companies fund a work on a feature nobody is paying us to do the maintance, … . I state this here because especially in the Eclipse Universe people are not so used to deal with projects not backed by at least one company.

OS-X, Java-Update and subversion frustration

All of a sudden my Subversion integration stopped working in all my various Eclipse-Versions which as you can imagine is a really huge problem in a coperate environment.

We are working with a lot of different companies around the world and most of them use Subversion as their version control system, the authentification is done through p12-certitifcates and this is where the problem starts:

Apples latest Java update introduced a change in how the authentification negotiation is done and this makes the SVNKit-Implementation fail to proper authentificate on the server (going into an infinite loop).

You now might think that only OS-X users are affected but installing Ubuntu and running with the latest OpenJDK/Sun-JDK has the same problem. So if you want to use Subversion + Java + Eclipse through the SVNKit-Connector you’ll have to go back to Java 1.6.0_17 which is quite easy on Linux but I haven’t found a way to do it on OS-X.

So what am I doing now?

  • Installed Virtual Box: What an amazing cooling Desktop Virtualization Software
  • Installed Ubuntu: Works just great
  • Created a virtual folder in Virtual Box pointing to my OS-X-Documents Folder
  • Mounted it in by adding the following line to my /etc/fstab
    ´╗┐´╗┐HostDocuments   /mnt/HostDocuments      vboxsf  uid=1000,gid=1000       0       0
    
  • Downloaded the Sun-JDK 1.6.0_17
  • Launching eclipse on Linux with
    eclipse -vm /opt/jdk1.6.0_17/bin/java
    
  • Imported project referencing the real ones on my OS-X-Filesystem

This means whenever I’ll have to commit I’ll bring up my Virtual-Linux (which is sitting in the background), refresh the projects and commit them. Once I’m back to normal work hopefully quite soon I’ll try to look into the SVNKit-Sources to fix the problem in their code which has been reported already a while back (if it is the correct bug then it was 2009-03-17).

e4 – A forward compat layer

In my last post I started explaining how one can write a so called forward compat layer for a custom application.

In the blog post I’ll present the first available bits of such a layer provided as part of the e4-Tooling effort. The idea of the forward compat layer is that you use the e4-Programming Model and write pure e4 POJOs which can be hosted inside an 3.x/4.0 workbench. Let’s at first look at the big picture how an e4-Application and 4.0 Workbench look like.

A pure e4-Application looks like this:

A 4.0 SDK with the backward layer like this:

An 3.x/4.0 SDK with Forward Compat Layer like this:

As the picture shows, the idea in the forward compat layer is to setup an DI-Container in a running 3.x Workbench and reusing the DI-Container provided in a 4.0-SDK Workbench.

Now that we know the background how can we work with it. The first thing to do is to write a Simple POJO which use an OSGi-Service of the type ITranslatorProvider:

package at.bestsolution.translate.view;

import javax.inject.Inject;
import org.eclipse.e4.core.di.annotations.Optional;

import org.eclipse.swt.widgets.Composite;
import at.bestsolution.translate.services.ITranslatorProvider;

public class TranslatorComponent {
  @Inject
  public TranslatorComponent(Composite parent) {
    createUI(parent);
  }

  @Inject
  void setTranslationProvider(@Optional ITranslatorProvider provider) {
    // Get the OSGi-Service injected    
  }
}

You should notice that the only “framework”-code we are depdending on is a bundle which defines the annotation we are using. Typically the components are kept in an extra bundle which has only dependencies on DI-Stuff.

If we want to integrate ourselves into a 3.x/4.0 SDK we somehow need to register our POJO in the DI-Container which is done in an e4-World by the ApplicationModel.

To register our View/EditorPOJO we are using specialized containers named DIViewPart/DIEditorPart like this:

public class TranslatorView extends DIViewPart<TranslatorComponent> {
   public TranslatorView() {
     super(TranslatorComponent.class);
   }
}

which itself is registered in the 3.x/4.0 Workbench using the views-extension point:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
   <extension
         point="org.eclipse.ui.views">
      <category
            name="Utilities"
            id="at.bestsolution.translate.view">
      </category>
      <view
            name="Translator View"
            icon="icons/page_find.png"
            category="at.bestsolution.translate.view"
            class="at.bestsolution.translate.view.TranslatorView"
            id="at.bestsolution.translate.view.TranslatorView">
      </view>
   </extension>

</plugin>

The 3.x/4.0 integration is typically kept in a bundle which depends on the bundle with the component(s) and the standard set of 3.x plugins like (org.eclipse.ui, …).