eclipse-dev

I'm moving to Wordpress

2009-06-07T16:12:00.001+02:00

In the last few days I moved this blog to wordpress and you can reach the content through http://tomsondev.bestsolution.at/

Useing Qt to write Equinox-OSGi-UI-Applications

2009-05-23T20:45:00.012+02:00

I saw I didn't blogged since about 2 months. So I thought I'll start a series of blog entries showing off new things and paths I'm exploring.

I'll start with a Technical Topic because it's a really exciting thing I guess not only for me but also for the whole Equinox-OSGi/Java-Community.

Since some time Qt is released under LGPL and since some weeks now their Java-Binding named Qt-Jambi is released too under LGPL. I've been playing with Qt-Jambi (because my UFaceKit project has a Qt-Port) before but now that the code is under LGPL it's getting more interesting to the wider Java-audience and naturally also people who use Equinox-OSGi for their applications.

A simple QtJambi-Application

Before digging into the details what I've done let's look at a simply QtJambi-Application if we are not using Equinox-OSGi.

package at.bestsolution.qt;

import com.trolltech.qt.gui.QApplication;
import com.trolltech.qt.gui.QGridLayout;
import com.trolltech.qt.gui.QLabel;
import com.trolltech.qt.gui.QLineEdit;
import com.trolltech.qt.gui.QMainWindow;
import com.trolltech.qt.gui.QWidget;

public class HelloWorld extends QMainWindow {

 public HelloWorld() {
   setWindowTitle("Hello World!");

   QWidget composite = new QWidget();
  
   QGridLayout layout = new QGridLayout();
   composite.setLayout(layout);
  
   QLabel label = new QLabel();
   label.setText("Label");
   layout.addWidget(label,0,0);
  
   QLineEdit text = new QLineEdit();
   layout.addWidget(text,0,1);
  
   setCentralWidget(composite);
 }
 
 public static void main(String[] args) {
   QApplication.initialize(new String[0]);
  
   HelloWorld world = new HelloWorld();
   world.show();
  
   QApplication.exec();
 }
}

This looks not much different to a SWT-Application besides the fact that one doesn't has to pass a parent when creating a widget and instead of running the event loop one simply calls QApplication.exec().

QtJambi and Equinox-OSGi

Couldn't be hard you think when you've used other UI-Toolkits (SWT,Swing) in your Equinox-OSGi-Applications already but the problem is that Swing is not problematic because it is part of the JRE and SWT is shipped as an (in fact multiple) Equinox-OSGi-Bundle/Fragment.

What we need to do is to Equinox-OSGify the bundles coming from Qt but this task is more complex then it looks on the first sight because using the simple converter provided by PDE is not providing us a solution because QtJambi-Code expects to load the libraries in very special way which means we need to patch their Java-Code to make it aware of Equinox-OSGi.

The really cool thing is that patching and maintaining the patch is easier than one might think because they provide their sources through a git-repo one could simply clone and maintain the patched sources. So maintaining the patch is easier than it is for example to maintain a patch for the eclipse-platform because of git.

The tough thing is to get the environment setup in a way than one can produce .jars from the sources because one

Has to compile the Qt-Sources

To generate the Java-Binding-Classes to the Qt-Sources (extracted from the C++-Header-Files)

which is a bit time consuming and not documented very well at the moment. Though this is doable for a medium skilled Java-Dev I think one should be able to checkout the complete project with native and generated Java-Code and doesn't have to compile all the stuff.

After having managed to setup a build environment I patched the libary loading classes and recreated the .jar-packages. QtJambi is split in 2 .jars:

qtjambi.jar: Hold platform independent Java-Classes

qtjambi-${os}.jar: Holding native libraries for the platform and the JNI-Glue

So the setup is similar to SWT but in SWT also the Java-Code is part of the native fragment because it differs from platform to platform and the host bundle is simply an empty bundle. In contrast to that in Qt the Host-Bundle is holding all Java-Classes and in the native fragments one has the native-libs and JNI-Glue.

So what this all means for you? Not too much because I did 2 things as part of UFaceKit-Target-Setup:

Packaged my changes to the Java-Code and provide it for download

Added ant-tasks who fetch the native libs from Qt-Software and repackage them

One could also use these ant-tasks when not using UFaceKit (I'm using it for my RCP-Development-Setup).

The Equinox-OSGi-Support is not fully finished and I'll maybe rework it a bit in future when understanding the code better but for now it sufficient to go on and file a CQ to make use of Qt in UFaceKit. Let's see what's coming out from this now that Qt is LGPL.

Simple Qt-Jambi and Equinox-OSGi-Application

Let's create an Equinox-Application which uses Qt as UI-Toolkit now. The easiest thing is to use the PDE-Wizard to create a "Headless Hello RCP" and add a MainWindow.java.

package at.bestsolution.qt;

import java.io.BufferedReader;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;

import com.trolltech.qt.gui.QApplication;
import com.trolltech.qt.gui.QGridLayout;
import com.trolltech.qt.gui.QLabel;
import com.trolltech.qt.gui.QLineEdit;
import com.trolltech.qt.gui.QMainWindow;
import com.trolltech.qt.gui.QPixmap;
import com.trolltech.qt.gui.QPushButton;
import com.trolltech.qt.gui.QWidget;

public class MainWindow extends QMainWindow {
 
 public MainWindow() {
   QWidget widget = new QWidget();
   widget.setObjectName("main_window");

   QGridLayout layout = new QGridLayout();
   layout.setMargin(0);
   widget.setLayout(layout);  
  
   addHeader(layout,"Tom Schindl","at/bestsolution/qt/bookmarks.png");
  
   QWidget content = new QWidget();
   QGridLayout contentLayout = new QGridLayout();
   content.setLayout(contentLayout);
  
   addLine(0, contentLayout, "Firstname");
   addLine(1, contentLayout, "Lastname");
   addLine(2, contentLayout, "Age");
  
   QPushButton button = new QPushButton();
   button.setObjectName("submit");
   button.setText("Submit");
   contentLayout.addWidget(button,3,1);
  
   layout.addWidget(content);
  
   setCentralWidget(widget);
 }
 
 private void addHeader(QGridLayout layout, String labelText, String icon) {
   QLabel header = new QLabel();
   layout.addWidget(header);
   header.setObjectName("header");
   QGridLayout headerLayout = new QGridLayout();
   headerLayout.setMargin(0);
   header.setLayout(headerLayout);
  
   QLabel headerIcon = new QLabel();  
   headerIcon.setObjectName("header_icon");
   headerIcon.setPixmap(loadImage(icon));
  
   headerLayout.addWidget(headerIcon);
  
   QLabel headerText = new QLabel();
   headerLayout.addWidget(headerText,0,1);
   headerLayout.setColumnStretch(1, 100);
   headerText.setObjectName("header_text");
   headerText.setText(labelText);
 }
 
 private void addLine(int line, QGridLayout contentLayout, String labelText) {
   QLabel label = new QLabel();
   label.setText(labelText);
   label.setObjectName("label");
   contentLayout.addWidget(label);
  
   QLineEdit text = new QLineEdit();
   text.setObjectName("text");
   contentLayout.addWidget(text,line,1);
 }

 
 private QPixmap loadImage(String path) {
   try {
     InputStream in = getClass().getClassLoader().getResourceAsStream(path);
     ByteArrayOutputStream out = new ByteArrayOutputStream();

     int l;
     byte[] buffer = new byte[1024];

     while ((l = in.read(buffer)) != -1) {
       out.write(buffer, 0, l);
     }

     QPixmap pic = new QPixmap();
     pic.loadFromData(out.toByteArray());
     return pic;
   } catch (Exception e) {
     e.printStackTrace();
   }

   return null;
 }
}

and modify the generated application class like this:

package at.bestsolution.qt;

import org.eclipse.equinox.app.IApplication;
import org.eclipse.equinox.app.IApplicationContext;

import com.trolltech.qt.gui.QApplication;

public class Application implements IApplication {
 public Object start(IApplicationContext context) throws Exception {
   QApplication.initialize(new String[0]);

   MainWindow window = new MainWindow();
   window.show();
  
   QApplication.exec();
  
   return IApplication.EXIT_OK;
 }

  public void stop() {}
}

Well as you see I'm not a good designer and the application looks well not really nice though it looks native on my OS-X though this is only faked by Qt because they are drawing everything on the screen as far as I understood it.

One could think that this fact is a draw back of Qt but IMHO it's the other way round because with this strategy they can support things SWT can't support easily - Completely restyle your application using a declarative language and well they use CSS like e.g. E4 does too.

The first thing to do is to add a method to load a stylesheet to Application.java:

private String loadStyles(String cssPath) {
 InputStream in = getClass().getClassLoader().getResourceAsStream(cssPath);
 BufferedReader r = new BufferedReader(new InputStreamReader(in));
 StringBuilder s = new StringBuilder();
 String line;

 try {
   while( (line = r.readLine()) != null ) {
     s.append(line);
   }
 } catch (IOException e) {
   e.printStackTrace();
 }

 return s.toString();
}

and set the style sheet on the main window:

public Object start(IApplicationContext context) throws Exception {
 QApplication.initialize(new String[0]);
  
 MainWindow window = new MainWindow();
 window.setStyleSheet(loadStyles("at/bestsolution/qt/style.css"));
 window.show();
  
 QApplication.exec();
  
 return IApplication.EXIT_OK;
}

and we need to define some styles:

resulting in this application:

which we all agree looks better than:

As you see this is also not my design but then one you get when using the Eclipse-Forms-API with the difference that in Eclipse one has to learn a new API to deal with besides SWT whereas in Qt the UI-Code is still Qt and styled by a declarative syntax and if you ask me the Forms-API is going to replace in space of Eclipse in E4 through SWT + CSS but this is only my personal opinion.

So should we all now move to Qt-Jambi to write UI-Applications in Java like we did years ago when we abandoned Swing and started using SWT?

Let's look at some potentially problematic areas:

Qt and QtJambi misses an application framework like eclipse RCP provides one for SWT-Application developers

Qt and QtJambi misses Databinding support like Eclipse-Databinding provides one for SWT, JavaBeans and EMF

Nokia removed all resources from QtJambi development and wants to build a community to work on it

For at least 2 of the above there are solutions already today:

E4's core application platform is UI-Toolkit agonstic so though E4 is not released until 1.5 years it would give people the possibility to use Qt as their UI-Toolkit of choice which supports many many things starting from animations, multimedia integration, ...

UFaceKit provides JFace-Viewer like and Eclipse-Databinding support for QtJambi if the CQ I'm going to file is approved

Still the killer problem is the lacking support from Nokia on QtJambi and it's unclear if a community could be build around it who not even maintains but also adds new features.

I think this is a bitty because with getting a real application framework with E4, it's themeing, multimedia and animation support I think QtJambi could get a real possibility to write cross-platform RCP-Applications in Java without the sometimes really hurting lowest common denominator problem we have in SWT.

So what should one do? Though QtJambi looks like a real solution for writing nice looking RCP-Applications the uncertainness caused by Nokia by cutting resources makes it unusable for most companies.

For form developers I could point you once more to UFaceKit which supports both SWT and Qt and your form application code is not affected by changing the underlying technology but one can still rely on native stuff where needed (e.g. using Qt animation/multimedia support).

For me as one of E4 committers and UFaceKit-Project lead it means:

I'd try to keep the application runtime widget agonstic if possible (well we are on a good track here)

I'll file a CQ to let UFaceKit make use of QtJambi and provide first class JFace-Viewer and Eclipse-Databinding support for QtJambi

1. updated my wrong capitalization of Qt

2. please note that I'm using Equinox specific stuff to make this work so it is maybe not runnable on other OSGi implementations but I'm happy to incooperate feedback and suggestions into my git-clone to support other OSGi implementations

Give your E4-Application a modern Look&Feel

2009-03-02T11:28:00.008+01:00

EclipseCon is coming in about 3 weeks and I started preparing the stuff for my talks about E4 and UFaceKit.

In E4 we are trying to address some of the main pain points RCP-Application developers faced - Their application looks like Eclipse and the theming/presentation API is not flexible enough to modify all aspects of the UI (e.g. Toolbar/MenuBar, ...)!

The first step to make your application look different was that we introduced the concept of declarative styleing (CSS).

Let's take the demo E4-Photo-Demo-application as example.
This is the application without CSS:

This is the application with CSS:

But like in other aspects E4 goes further and allows you to exchange complete widgets like the application-shell, the menu and toolbar, the Stack-Folders (the standard theme uses CTabFolder) resulting in an E4-Demo-Application like this:

You want to know more about how this works and how the internals of the workbench make such things possible? Then I'd suggest to you attend the EcliseCon-talk about the modeled workbench Boris and I are delivering at EclipseCon09

But E4 goes even further! It allows you to plugin every widget-technology you want to! The internals don't care whether your application gets renderered by QT, Swing, UFaceKit you name it. So I've done that and here's my UFaceKit-Demo-Application built on top of E4:
Makeing UFaceKit a possible renderer of E4 opens the doors to all technologies supported by UFaceKit (Swing, QT, GWT, ...) and its advanced DeclartiveStyling-Support

News on UFaceKit

2009-02-27T00:06:00.003+01:00

IP-Review passed

This is a great day in the short life of UFaceKit. We passed the initial IP-Review for our code base and I thank all the IP-Team for the great assistance and help to make our code base IP-clean.

Abstraction of Application-Bootstrapping

Until today the start up process of an application has been Toolkit specific (e.g. spinning the event-loop) this is now abstracted in a new interface called UIDesktop which can be compared to the mixture of SWT-Display and the Eclipse-Workbench.

This abstraction means that switching from SWT to QT means switching exactly one factory and that's it. This new UIDesktop concept is also a result of discussing a potential OpenGL-Implementation of the UFaceKit-API with one of our employees.


public void startup(UIFactory factory) {
  UIDesktop desktop = factory.newDesktop();

  desktop.runWithDefaultRealm(new UIRunnable() {

    @Override
    protected IStatus run(UIDesktop element) {
      createUI(element,uiMethod);
      return Status.OK_STATUS;
    }
  });

  desktop.run();
}

// Creating application with SWT
startup(new JFaceFactory());

// Creating application with QT
startup(new QTFactory());

A first real world application

One of our employees is rewritting our one of our applications using UFaceKit and is making good progress. Writing a real world applications helps us to fill the last missing gaps in API. Maybe I can already show an intial version of the application on EclipseCon 09 then people can see a real world application using UFaceKit + EMF + CDO in my talks:

Mixing Eclipse Technologies to create Enterprise Ready Database-RCP-Frontends

UFaceKit - A highlevel Databinding and Widget-Toolkit-Abstraction

By the way I'm nominated for 2 Eclipse-Awards

Top Ambassador

Top Contributor

Getting started with UFaceKit and QT

2009-01-17T02:36:00.005+01:00

QT and UFaceKit

So the big news this week in opensource space was the announcement of Nokia to release their C++ cross-platform widget toolkit under LGPL. This is great and people now once more start to request a SWT-Port for QT. I don't know if any company is going to invest the development resources into such a port at least I haven't heard anything.

From UFaceKit point of view the announcement is great because we've been working since some time on an UFaceKit-Implementation for QT. Today I invested some time to implement features to render the AddressBook-Application i showed you in my last blog entry

Below is the application rendered using the CleanlooksStyle on MacOSX:

The only change to the code I showed you last week is how the application is launched.
For SWT the launcher looks like this:

public class Launcher {
  public static void main(String[] args) {
    final Display display = new Display();

    Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {
      public void run() {
        JFaceFactory factory = new JFaceFactory();
        Workbench workbench = new Workbench(factory);
        workbench.open();

        while( ! workbench.isDisposed() ) {
          if( ! display.readAndDispatch() ) {
            display.sleep();
          }
        }
      }
    });
  }
}

And for QT:

public class Launcher {
  public static void main(String[] args) {
    QApplication.initialize(new String[0]);
    QApplication.setStyle(new QCleanlooksStyle());
    
    Realm.runWithDefault(QTObservables.getRealm(), new Runnable() {
      public void run() {
        QTFactory factory = new QTFactory();
        Workbench workbench = new Workbench(factory);
        workbench.open();
        QApplication.exec();
      }
    });
  }
}

And now with styles applied the whole application looks like this:

I'm still in the process to make myself familiar with the QT-API and how I'm supposed to use and implement certain functions. Even if you don't want to use our UFaceKit-API the work we are doing here is interesting to you probably because we provide for example QTObservables for use with Eclipse-Databinding and a Combo/List/Table/Tree-Viewer implementation for QT-Controls.

UFaceKit Dokuware

I was asked to provide instructions how to get the applications I show in my blog running the locally and play with them. I've opened a new section in the Eclipse-Wiki holding all informations about our project - outlining our goals, instructions how to get the current code base running, and hopefully much more information soon.

Pimp your application L&F with UFaceKit

2009-01-14T01:32:00.009+01:00

Does your application look like this or hopefully a bit better than this really ugly example?

Making applications look nice and still not cluttering your code with these theming informations is something not provided out of the box by Eclipse. Still the situation is changing since the E4-Team is working on "native" SWT-CSS integration (Kevin McGuire and Kai Tödter) - if I'm not mistaken the code should in theory also work in 3.x.

But besides E4 there's another project called UFaceKit which provides a high-level widget-toolkit API (the application above is written with UFaceKit in about ~250 Lines of code) and part of this high-level abstraction is direct support for Declarative-Styleing.

Let's at first take a look at the above application. I've split it into 3 Classes:

Workbench.java: Creates the workbench and the TabFolder

ContactsPart.java: Creates the Content shown in the Contacts-TabItem

DetailsPart.java: Creates the Content shown in the Details-TabItem

When coding with UFaceKit and you choose to use the SWT-Implementation (we also provide Swing and QT though SWT is the most stable and feature rich) you get the native platform L&F (as you see above) but the application is not really visually appealing.

If you don't have support for declarative styling you'd now have to clutter your code with themeing informations (e.g. setting background-colors, ...) and your code is soon getting unmaintainable. The Web-Guys already found this out for a while and invented CascadingStyleSheets (CSS). So why not learning from them and bring CSS (I more like the term Declarative-Styleing) to the world of Java-Desktops.

As mentionned before the E4-Team is working on CSS support and so does UFaceKit but this is not the only thing. UFaceKit abstracts styling support and you can plug-in your own declarative syntax. Out of the box we support:

CSS: Like you know it from Web-Development. We currently don't support all features from CSS2 but only the most important ones

USML: UFaceKitStylingMarkupLanguage is a very simply XML-Definition for css-like styles which has the adavantage that it doesn't add any dependencies like CSS-Support does

As state we don't suppport all features CSS2 defines but a subset of the most important things:

ID-Definitions like #myelement { }

Class-Definitions like .mylabel { }

Element-Definitions like UILabel { }

Support for pseudo-Attributes like :hover, :focus

Support for attribute-selectors like .mylabel[@value >= 10]

Let's see what we can achieve by adding this styling support our application.

Amazing isn't it? No single line of application code has changed between those screenshots! As you might noticed I've used Kai Tödters E4-Example application as master and the data is backed up in XMI useing the EMF-Toolchain.

What can you expect in future from UFaceKit:

Working on better support for Swing (many Styling things are missing)

Working on better support for QT (some styling and control things are missing)

Finishing implementation of current API functions

Adding JUnit-Test, ...

Declarative Syntax to describe and visual design your UI using EMF

As you see there's much work that needs to be done and if you are interested in helping out you are more than welcome.

Where do you go (JFace)Viewers

2009-01-08T21:19:00.008+01:00

The presence

Today I thought about a problem of JFace-Viewers when it comes to clever memory management like it is provided for example by CDO. CDO has a very clever memory management concept where objects are swapped out of the memory if they are not referenced in application code.

When using CDO in conjunction with JFace-Viewers this concept doesn't work because JFace-Viewers restore the model element into the TableItem/TreeItem-data-slot and so CDOs clever memory management is not working and the whole model resides in memory.

Inspired by Ed's efforts to minimize the memory footprint of EObject (see bug 252501), I started to think how we could improve on the other side of the fence. I've started today implementing a set of specialized viewer classes which makes it possible for you to take advantage of the clever memory management supplied for example by CDO.

The idea is simple. Instead of restoring the real object in the viewer the object gets translated into a key value (in case of CDO it could the a CDOID) and so CDO can free memory ASAP. The code is available from the UFaceKit-Repository because the scope of UFaceKit is also to provide higherlevel utilities for current Eclipse-Technologies beside inventing it's own high-level API.

The future

The Viewer-Concept provided by JFace for StructuredControls (Combo, List, Table, Tree, TreeTable) is one of the most used concept in Eclipse-Applications and although they are very powerful and we fixed many deficiencies we could provide much better useablility and user experience in E4.

Some of them coming to my mind are:

No Toolkit-Independence we can only target SWT like controls

Usage of Java5 generics

Multiple different APIs to achieve solve a problem

Problem with memory intensive models

(Fill in your favorite problem)

If you are a regular reader of my blog you know that in my UFaceKit-Project I've already written a JFace-Viewer like implementation for other widget toolkits (QT, Swing). I've today restarted think whether this would be a good thing for E4 in general and so I filed bug 260451.

I'd like to see Eclipse-Viewer getting a project like Eclipse-Databinding which is split into a general and toolkit specific part and integrate itself seamless into the concepts provided by Eclipse-Databinding. I'd invite all of you to take part in a renewed implementation of the viewer concept by adding yourself to bug 260451 and take part in the design discussion hopefully takeing place there.

The intial list of points I'd mentionned in the bug are:

Cross-Toolkit like Eclipse-Databinding I'd like to see Viewers getting split
a Toolkit-Neutral and Toolkit-Specific API so that implementation for e.g.
Swing, QT, ... can be created.

Better support for big model graphs (e.g. better support for CDO) (see bug
260422)

Revised inline editing

Direct-Databinding support

Builtin support Async-Programming (see bug 253777)

Support for Java5-Generics

Builtin databinding support (e.g. a Viewer could direclty implement the
IObservableValue interface)

Back from ESE

2008-11-21T11:49:00.006+01:00

I'm back in reality and just recap what happened the last 4 days.

My talks

Let me first recap my talks. I think all in all they went quite well though there are always things to improve (it was my first time doing a talk my own)

E4 - Modeling the workbench

I think I never talked to so many people ever before because I did my presentation in the biggest room available.I think I got the message around what the E4 project is about and in particular what the subtask-team I'm in is doing. The first reviews tell me that I didn't fail but I look forward for more comments.After my talk many people showed up personally. From what I can tell they agree with us about heading in the right direction. I think I even got the message about the joy, passion and openess the current E4-team is working together around that good that people think about joining us and bring in their own vision about the future of the Eclipse Platform. Hope to see you soon showing up at the E4-Mailing list.

Datacentric RCP with EMF and Databinding

I did the presentation in the 2nd biggest room and there even haven't been enough chairs for all people who wanted to attend my talk so they had to stand in the back. Woohoo.

I felt more comfortable speaking without a microphone and I think I showed people when mixing the right Eclipse technologies it's possible to write Enterprise ready Database frontends.

I admit my presentation was a bit focused about UI (Key-Binding, UI-Contexts, Commands) and not so how to access data. The only review I found until now is a short sentence in Ed Merks blog where people told him that the talk was "really good". So looking forward for more comments. I think the small application I presented there is what many people requested on the "E4-symposia" when they asked about a best practice example.

I even thought about restarting on an accompanying book about all the stuff one can find in the example and technologies but dismissed this thought immediately because I simply don't have the time and financial grounding to spend my time on it. The time (=money) my small company is investing in Eclipse is big enough already.

Conclusion

I would appreciate to get more comments about my presentation and ask myself why the same we had one EclipseCon was done where people got small pieces of paper to give back comments.

I think the intention was that people use gPublication to do so but it looks like people don't know about this. So if you want to give feedback and get access to the slides please do so at:

E4-Modeling the workbench: here

Datacentric RCP: here

but I'm afraid not all people attending my talks are really following my blog or the Planet so the feedback is going to be less than it was on EclipseCon.

If you and your company need help to get started with Eclipse RCP and other Eclipse technologies like OSGi, the modeling stack like (EMF, Teneo, CDO) my company is offering consultancy and development resources to anyone interested.

The E4 symposia

The symposia once more was I think a well received offer of Eclipse Summit Europe to the community and we talked about a lot different things in the E4 space. Boris Bokowski summarized the symposia in here.

For me as someone taking part in E4 project it is important to get feedback from the community to integrate their wishes (if my time permits) in the code base.

Socializing

I got to know my new people and we had a lot of interesting chats about new ideas (e.g. declarative ui) so it's hard to get back to reality and working on all those boring stuff.

Rotating Image in a PaintListener

2008-11-04T14:15:00.002+01:00

For those who have a better understanding of matrices and 2-D graphics this may sound strange but today I struggeled about 2 hours rotating an image in a PaintListener.

Let me first of explain the exercise I had to solve, then show you my solution and then maybe someone can point out a better one.

Exercise

Draw an Image at Point(50,50) in a Canvas which is rotated a variable angle.

The solution

Solveing this problem one can use a SWT-Transform to adjust the Graphics-Context looks straight forward but it took me like said 2 hours to wrap my head around the problem. The following function is the solution I came up with.


public void paintControl(PaintEvent e) {
  GC gc = e.gc;
  gc.setAdvanced(true);
  
  Bounds b = image.getBounds();

  Transform transform = new Transform(display);
  // The rotation point is the center of the image
  transform.translate(50 + b.width/2, 50 + b.height/2);
  // Rotate
  transform.rotate(45);
  // Back to the orginal coordinate system
  transform.translate(-50 - b.width/2, -50 - b.height/2);
  gc.setTransform(transform);
  gc.drawImage(image, 50, 50);
  transform.dispose();
}

Is the solution right? Is there a better solution?

My skills are very very bad when it comes to matrices and 2-D graphics so the above solution to the problem might be completely wrong and only works by chance.

News about UFacekit

2008-10-27T21:50:00.004+01:00

There are some important news I'd like to share with all of you:

1. UFacekit Proposal

The proposal is out and we hope some of you are interested in the targets and ideas we follow with UFacekit. If you are please leave a note on the newly created newsgroup. Share your wishes, critism with us so that we can make UFacekit a success.

2. QT-Port

Just a few minutes ago I checked in a first running version of a QT-Port of the UFacekit-API. Besides providing this API we naturally provide bundles you can consume standalone (e.g. to only use a JFace-Viewer-API in QT-Jambi-Projects, ...).

So we now have:

Support for SWT/JFace

Support for Swing

Support for QT (Cleanlooks Style)

Platforms I'd like to see a port in future:

GWT - is going to be revived soon by one of the team-members
- GXT
- Other UI-Toolkits based upon GWT

Eclipse-Forms - Should be fairly easy to do

Android - The first test suggest it is possible though we need to see if all widget types are available. Maybe we can only provide some viewer and UI-Observables but not a full fledged UFace-API

Platforms I dream of a port in future:

Draw2d

OpenGL

There's no place where Eclipse-Databinding doesn't work

2008-10-24T02:38:00.005+02:00

Tonight I thought I'll give Android a spin, I download the sources and worked through some samples. After an hour this got boring and because I already managed to get Eclipse-Databinding working in other Environments (GWT, Swing, QT) I thought now it is time to see if I can manage to get a minimal example working on Android.
Here's the application:

The model code looks like this (I'm using UBeans here because they are completely self contained and have no dependencies)


 private static class Person extends UBean {
  public static final int NAME = 1;

  public String getName() {
   return (String) get(NAME);
  }

  public void setName(String name) {
   set(NAME, name);
  }

  @Override
  public Object getValueType(int featureId) {
   return String.class;
  }

 };

The UI-Code looks like this (fairly straight forward UI-Code):


        TextView view = new TextView(this);
        view.setText("Name: ");
        TableLayout layout = new TableLayout(this);
        layout.addView(view);

        EditText text = new EditText(this);
        layout.addView(text);

        Button button = new Button(this);
        button.setText("Say Hello");
        button.setOnClickListener(new OnClickListener() {

   public void onClick(View v) {
    Dialog dialog = new Dialog(Test.this);
    dialog.setTitle("Hello " + p.getName() + "!");
    dialog.show();
   }

        });
        layout.addView(button);

And now the important thing how do we connect UI and Model-Attributes? Right we use Eclipse-Databinding (well not the one you get from Eclipse directly because it doesn't compile out of the box but patching it took about 30 minutes :-).


        IObservableValue mObs = UBeansObservables.observeValue(realm, p, Person.NAME);
        IObservableValue uiObs = AndroidObservables.observeText(realm, text);
        DataBindingContext ctx = new DataBindingContext(realm);
        ctx.bindValue(uiObs, mObs, null, null);

Cool isn't it? Would a Eclipse-Databinding port for Android help you? Then take a look at the newly proposed Eclipse-Project UFacekit. We already provide Viewer and UI-Observable implementations for different Platforms (SWT,Swing,QT) and plan to provide one for other platforms (GWT, Eclipse-Forms, ... you name it). Why should we not provide them for Android-Widgets too?

Update on UFacekit

2008-10-19T23:13:00.004+02:00

UFacekit has a new source structure

We have restructured the repository to clearly separate our modules into:

proper:

This holds stable and actively maintained modules - currently Swing and SWT implementations. Checking them out and compiling works always else it's a bug and someone is to blame.

incubation:

This holds newly and not yet stable modules - currently our new brand new QT support is in there. Checking them out and compiling works most of the times it's not a bug!

dormant:

This holds old modules currently not actively maintained and don't even compile. Sad enough our GWT ports are currently located there. Hopefully we are good to push them forwards once more in the next months. You are a GWT guru and want to help making the GWT port as stable as possible? Come and join us.

The layout is taken from the Apache-Jakrata project.

UFacekit has an QT-Port

I started 2 or 3 weeks ago a port which uses QT-Jambi to bind against QT-Widgets. There's no ufacekit API available but Viewer implementation and observables for some widgets are already available. I hope I can finish this work as soon as possible. Might be interesting what happens when we are moving the sources to Eclipse.

UFacekit has a build story

Having a stable build story is one of the most important things for OpenSource-Projects. Kenneth did amazing work on making UFacekit managed and build with maven. The repository now doesn't hold any IDE-specific settings any more everything is done by maven.
We are not using PDE-build or any Eclipse-specific things because this would interfere with an important UFacekit-target:
"improve adoption of Eclipse Core technologies (like Eclipse-Databinding) outside RCP and SWT (e.g. Swing, GWT, QT)". Having a build story relying on Eclipse would be a bad thing.

The process e.g. for the proper-modules is like this:


svn co http://uface.googlecode.com/svn/trunk/proper/
cd proper
cd org.ufacekit
mvn clean install
mvn eclipse:eclipse

Afterwards fire up eclipse and import the modules. Done. Kenneth you are my king.

Disable parts SWT-Table/Tree with SWT.CHECK

2008-10-08T18:23:00.002+02:00

This is a hack, a hack, a hack posting.

I have read many many entries on the newsgroups asking a question like this:


How can I disable certain check boxes in an SWT-Tree/Table. Is this possible?

The standard answer to this was: "Sorry no this is not possible". Today I faced the same problem (mine had to do with ViewerObservables#observeCheckElements()) where the user is not allowed to check the Top-Level-Nodes.

The tree looks like this:


+ Application 1
  + Privilege A
    + Privileg A1
  + Privilege B
    + Privileg B2
+ Application 1
  + Privileg C

The values bound are the ones in Privileg* so I have to lock the Application-checkboxes

The setup is something like this:


Databinding ctx = ....
IObservableSet mObs = ....

Tree tree = new Tree(parent,SWT.BORDER|SWT.V_SCROLL|SWT.H_SCROLL);
CheckBoxTreeViewer v = new CheckBoxTreeViewer(tree);
IObservableSet uiOs = ViewerObservables.observeCheckedElements(v,IPrivileges.class);
ctx.bindSet(uiObs,mObs,null,null);

I nearly gave up but then I had the following idea.


final Tree tree = new Tree(parent,SWT.BORDER|SWT.V_SCROLL|SWT.H_SCROLL);
// Attach a listener directly after the creation
tree.addListener(SWT.Selection,new Listener() {
   public void handleEvent(Event event) {
       if( event.detail == SWT.CHECK ) {
           if( !(event.item.getData() instanceof IPrivileg) ) {
              event.detail = SWT.NONE;
              event.type   = SWT.None;
              event.doIt   = false;
              try {
                 tree.setRedraw(false);
                 TreeItem item = (TreeItem)tree.item;
                 item.setChecked(! item.getChecked() );
              } finally {
                 tree.setRedraw(true);
              }
           }
       }
   }
});

CheckBoxTreeViewer v = new CheckBoxTreeViewer(tree);
// ....

This is a hack, I only tested it on Win32 (XP) and don't know how cross platform it is so don't kill me for posting this hack of hacks.

JFace-Viewers for Swing, is this possible?

2008-09-22T21:27:00.004+02:00

You might think "Now he's gone completely crazy" but hold on and read through the next few paragrpahs to hopefully find out that I'm not.

0. The background

Do you sometimes have to code against Swing and have also been disappointed that you could not remember how to deal with Tables, Trees and TreeTables (I find myself always opening this tedious Swing-Tutorial to find how to do it)?

In last few days I worked on UFacekit's Swing implementation for Tree and TreeTable. JFace-Databinding has added support for Trees and TreeTables in 3.4 and naturally they build upon the JFace-Viewer implementation but naturally JFace-Viewers are bound to SWT and so it is impossible to use this support (or a slighlty one modified) Swing, right?

Well the above is not completely right the main JFace-Viewer-API is fairly free from SWT (besides some Widget, Item stuff) the internals are naturally not. After having noticed this I:

1. Extracted an Widget-Toolkit-Neutral API from JFace

... moved it to a new plugin (org.ufacekit.ui.viewers). I didn't only move the classes and interfaces to a new home I also added support for generics so all this casting is gone and done by the compiler for us.

A content provider now looks like this:


IContentProvider<Person,Collection<Person>> cp = 
   new IContentProvider<Person,Collection<Person>> {
      // ...
}

and a collection can get iterated with a foreach-loop


for( Person p: v.getSelection() ) {
   // ...
}

I rearranged some other classes and made interfaces from most of them, ... . So now I have a widget-toolkit-clean Viewer-API.

2. Copied some SWT-Classes (Widget, Table, TableItem, Tree, ...)

... replaced the internals through Swing-counter parts (some of the code is highly ineffecient because e.g. for a Tree we now have 3 Objects (UserObject, TreeItem, DefaultMutableTreeNode) )

3. Commented some JFace-code not needed to provide the minimum JFace-API

... providing a selection, and firing events when the selection changed but I currently e.g. don't need inline Editing so I simply commented all parts of the viewers that deal with this, including Mouse-Handling, ... . The problems from 2. & 3. are hidden from the user because all these are internal classes so I can replace them step by step.

4. Blog how nicely now I can setup a TreeTableViewer for Swing

(in fact SwingX because Swing doesn't has a TreeTable implementation by default - don't ask me why a Toolkit being around for such a long time doesn't has such a standard-control)

So now I don't have to remember how I have to create a TableTree in Swing which loads subnodes lazily because I can simple use the API I already know from JFace for SWT.


@Override
protected Component createUI(JFrame frame, List<Person> model) {
  JXTreeTable tree = new JXTreeTable();

  TableColumnExt c1 = new TableColumnExt(1);
  c1.setHeaderValue("Givenname");
  c1.setWidth(200);
  tree.getColumnModel().addColumn(c1);

  TableColumnExt c2 = new TableColumnExt(1);
  c2.setHeaderValue("Surname");
  c2.setWidth(200);
  tree.getColumnModel().addColumn(c2);

  JScrollPane scroll = new JScrollPane(tree);

  TreeTableViewer<Person, Collection<Person>> viewer = 
     new TreeTableViewer<Person, Collection<Person>>(tree);
  viewer.addSelectionChangedListener(
    new ISelectionChangedListener<Person>() {
      public void selectionChanged(SelectionChangedEvent<Person> event) {
        for( Person p: event.getSelection() ) {
          System.out.println(p);
        }
      }
    });

  TreeViewerColumn<Person> c = new TreeViewerColumn<Person>(viewer,c1);
  c.setLabelProvider(new LabelConverter<Person>() {
    @Override
    public String getText(Person element) {
      return element.getGivenname();
    }
  });
  c = new TreeViewerColumn<Person>(viewer,c2);
  c.setLabelProvider(new LabelConverter<Person>() {
    @Override
    public String getText(Person element) {
      return element.getSurname();
    }
  });

  viewer.setContentProvider(
    new ITreeContentProvider<Person,Collection<Person>>() {
      public Collection<Person> getChildren(Person parentElement) {
        return parentElement.getChildren();
      }

      public Person getParent(Person element) {
        return element.getParent();
      }

      public boolean hasChildren(Person element) {
        return ((Person)element).getChildren().size() > 0;
      }

      public Collection<Person> getElements(Collection<Person> inputElement) {
        return inputElement;
      }

      public void dispose() {
        // TODO Auto-generated method stub
      }

      public void inputChanged(IViewer<Person, Collection<Person>> viewer, 
        Collection<Person> oldInput,
        Collection<Person> newInput) {
          // TODO Auto-generated method stub
      }
    });
  viewer.setInput(model);
  return scroll;
}

5. Summary

The internals are quite ugly there is a huge amount of bugs (I'm sure that not all is working smoothly already), missing functionality (e.g. Icon, Color and Font support) but I now have the foundation to add Tree and TreeTable support to the UFacekit-Library. Cleaning up and bugfixing can happen later. Like all other parts of the UFacekit-Project you can consume this swing-jface-bundle standalone because it has no dependency at all (besides the one on org.ufacekit.ui.viewers).

6. So am I now?

Completely Crazy

Fairly Crazy

A bit Crazy

Fairly normal if you know me and all the crazy ideas I already had

UFacekit - Proposed as a Component under Platform/Incubator

2008-09-09T09:39:00.002+02:00

So the news is out [Mailinglist, Newsgroups]. UFacekit is proposed as a Component under Platform/Incubator project (proposal). I think this is the right move for UFacekit to gather momentum towards our first release. If you want to support this move:

Comment on the following newsgroup post from Boris

Add yourself/company as an interested party on the proposal page

I'm currently working on the JavaDoc and for SWT/JFace a build should be available right after we moved the sources to foundations repositories, swiched namespaces, ... .

Exploring new technologies part of Ganymede-Release Train

2008-09-03T16:19:00.008+02:00

I took myself some time the last days exploring new technologies available with Ganymede 3.4:

Eclipse-Databinding and its new features

EMF-Databinding (Provisional but working very smoothly)

Teneo: Persist your model via hibernate in a SQL-Database

CDO: Share your model between different clients and persist it into an SQL-Database (with Revision support)

New Extension Points to enhance the Expression Framework

Spring & OSGi

P2 to install the Products using the P2-Agent

I did this to understand those technologies better because we at my company have to decide which technologies our next generation of products is built on (The current ones are based on selfwritten libs because at that time there was no Eclipse-Databinding, Teneo and CDO or we didn't knew about it).

As always when learning new technologies I created an example application but before I started I defined some goals I think are curcial to all Enterprise Datacentric Desktop Applications:

Nice L&F (as good as I can make an UI Look without a designer)

Plugable storage technology

Undo/Redo Support

Then I started hacking, creating an Ecore-Model, some plugins, extension points, browsing documentation and noticed that there are no examples around for most of the things I wanted use:

How to create an EditingDomain myself when not using the generated editor-classes from EMF?

How to use the new org.eclipse.ui.services-Extension point to enhance the expression framework?

Best strategy to use Extension Points when bundles are installed/uninstalled/updated while the application is running

All those things are not hard if you know how to do it but if you don't it's quite tricky to solve these problems. It even gets harder if the technologies you plan to use are quite new and/or are not used together and because of this bugs arise.

So the immediate output of my work was that 2 bugs [239015, 245183] in Eclipse-Databinding got fixed in 3.4.1.

The longterm output for me is:

I now have a good picture how our next technology stack looks like

I have an example application (I will add other things in the next weeks) to teach my co-workers the technologies

I had a lot of fun (besides struggeling with P2)

The longterm output for you is:

You have a small application showing you a lot of different concepts around RCP+EMF+Databinding applications
- EMF-Ecore
- Usage/Creation of your own Extension Points
- Using EditingDomain outside the scope of EMF-Generated artefacts
- Using Teneo
- Using CDO

I started summerizing all the ideas, technologies and concepts combined in this example in a document, I'm working on from time to time. So maybe some time you'll get a "book" explaining you everything

Some nice reusable classes e.g. one to use EMF/Databinding-LabelProviders with cool features, a new drop down widget showing a Tree in the popup, ...

This is the application:

If you want to run it locally get a copy of the P2-Agent and point the metadata repository and artifacts repository to this location.

To use the CDO-Version you also need a server component which can be installed when pointing the agent to this location. After having installed the CDO-Server you also have to create a CDO-Configuration (cdo-server.xml) in the installations "configuration" directory which you can fetch from here.

The repository name in the above config "CDO-1" has to be the id of the CDO-Configuration you create in your application.

Finally if you are interested only in the sources then install a subversion plugin in your eclipse and use one of te Team-ProjectSet files from here to check out the necessary projects.

If you want to learn more about these cool technologies. I've proposed beside a talk about E4 - The new platform-ui concepts a talk about this example application on ESE.

Writing a CTreeCombo-Widget

2008-08-24T18:10:00.005+02:00

I was working on my example RCP/EMF/Databinding application

I'm going to use to present various parts of those technologies to my co-workers and getting familiar with new technologies like CDO, Teneo, Spring and others when I hit the problem that standard CCombo didn't suited my needs.

What I wanted to have was a CCombo which presents a Tree like structure like this

for my Login-Screen and as you all know there's no such widget available currently. As you might guess from the above Screenshot I somehow managed to get such a widget.

Before we dive into it another requirement I had was that the implementation plugs itself into the existing viewer and databinding concepts of Eclipse.

So what did I do and how did it work? Well 95% of the work I had to do is C&P. I copied the CCombo-Code replaced List against Tree and solved compilation errors. To make a CTreeCombo widget I would have been done almost if this would have been the only requirement.

The real problem is that widgets are reparentable and that this can happen across Shells which makes it necessary to recreate the Tree and its popup shell from time to time so directly attaching a TreeViewer on the underlying Tree-Widget is not possible. So the only possibility was to create Proxy objects around TreeItem/TreeColumn who proxy the real implemementation so that they could be recreated whenever needed.

So if one wants to use the widget he/she has to write code like this:


int style = SWT.BORDER|SWT.READ_ONLY|SWT.FULL_SELECTION;
CTreeCombo combo = new CTreeCombo(shell,style);

CTreeComboItem item = new CTreeComboItem(combo,SWT.NONE);
item.setText("Parent 1");

CTreeComboItem childItem = new CTreeComboItem(item,SWT.NONE);
childItem.setText("Child 1.1");

childItem = new CTreeComboItem(item,SWT.NONE);
childItem.setText("Child 1.2");

item = new CTreeComboItem(combo,SWT.NONE);
item.setText("Parent 2");

childItem = new CTreeComboItem(item,SWT.NONE);
childItem.setText("Child 2.1");

childItem = new CTreeComboItem(item,SWT.NONE);
childItem.setText("Child 2.2");

CTreeCombo now works like an ordinary SWT-Tree providing the same API as SWT-Tree (at least currently the one which is necessary to write a JFace-Viewer) so that I could subclass AbstractTreeViewer and providing an implementation for it. So if one uses JFace-Viewers in his/her code they simply need to write:


int style = SWT.READ_ONLY|SWT.BORDER|SWT.FULL_SELECTION
CTreeCombo combo = new CTreeCombo(parent,style);

CTreeComboViewer viewer = new CTreeComboViewer(combo);
viewer.setLabelProvider(new LabelProviderImpl());
viewer.setContentProvider(new ContentProviderImpl());
viewer.setInput(input);

In the end it took me longer than I first thought but after 4 hours I had a working CTreeComboViewer (although it is not thoroughly tested yet) which behaves appropiately (at least in the way I currently use it).

If you are interested in the code of the widget or in the application to learn about:

Writing a modular RCP-Application

Using SWT, JFace and Databinding

Using EMF and EMF-Databinding

Using and creating your own Extension Points

Using and extending the Commands, Handlers and the Expression Framework

You can fetch the code from my companies svn-repository but the application is still in flux. If you are only interested in the widget and viewer code you can find it here for the widget and here for the viewer.

Ganymede - What's in JFace and Databinding

2008-06-13T15:28:00.005+02:00

The History

JFace-Viewers/ToolTips

In 3.3 the whole Viewer-Infrastructur has been reworked to make it easier to add new features in upcoming releases. Some new features where part of 3.3 (e.g. LabelProvider/Column, CellNavigation, Customizable-Editor). Additionally JFace opened up its viewers for subclassers by wrapping Widget-Specific API (ViewerRow/ViewerCell).

Databinding

3.3 saw the first public release of the Eclipse-Databinding-Framework which removes the need for myiards of listeners to keep your model and UI in sync. Anbody who ever had write a Master-Detail-UI knows how hard it is to get it right.

Today

JFace-Viewers

We saw great adoption of our new API and new features added ontop of it. The most significat one is a LabelProvider which understands StyledText-Instructions named StyledCellLabelProvider. You'll see this LabelProvider in action if you open the Java-ProjectExplorer.

On the other hand we also saw great adoption of our API-Opening-Up effort which allows widget vendors to provide a JFace-Viewer-API for their structured widgets. There are 2 Nebula-Components (Nebula-Gallery and Nebula-Grid) who already adopted the concept and provide a viewer.

Thanks for the great feedback and bug reports from the community we fixed some [92] problems and feature request some of them dating back to 2003!

In comparison to Europa-Release we didn't introduced much new API. From my point of the main focus was to evolve the new API we provided in 3.3 and fix problems which have been introduced. If you saw how much code has been rewritten in 3.3 I think this was thr right thing (although we fairly broke no backward code anyways in 3.3).

Databinding

Thanks to the community and Ed Merks and his team there's now a 2nd possibility to back up your UI with a model beside JavaBeans.

Naturally they provide integration for their EMF-Objects with 2 brand new plugins named org.eclipse.emf.databinding and org.eclipse.emf.databinding.edit. Those plugins are marked as provisional but I'm using them since day 1 in my projects and for the standard cases they just work fine and whenever a bug occurs it's fixed immediately. Give it a try and see how fast you can develop powerful SWT-UIs.

At the very moment you bring EMF into your project it opens up the door for fairly everything you and your customers ever dreamed of (take a look at the teneo to presist your model in a SQL-Database using hibernate, working with distributed objects using CDO, validating your model using OCL and much more).

On UI-Side of Databinding also many new features have been added. You have support for Inline-Editing in Table/TreeViewers (every control inheriting from it e.g. GridViewer), there's new support for Observable-TreeViewers and naturally many many bugfixes [75].

The future

JFace-Viewers/ToolTips

Naturally we are going to fix bugs and problems. I have already some bugs in my queue I can address after the Ganymede-Release is out of the doors. Looking at this back log of viewer bugs [228] I'm going to try to bring this bug count down a bit (say 200 is a good number).

Databinding

I see a bright future for databinding and I'll restart my work on bringing all this (databinding+emf) to the web using it in my GWT-Enabled applications inside my UFace-project if time permits.

Summary

I think all people worked on the projects above have done an amazing job. We fixed many bugs added many great new features, many with the help from the community whether they filed sensetational bug reports or even provided patches. A big thank goes out to you, the community.

One more note in the end. In time of 3.4 we saw the creation of a new project called E4. It was discussed controversial in the blog space and on mailling list as you all known.

After EclipseCon I decided as a community member to take part in this effort for the next generation of an UI-Framework provided by the Eclipse Organisation and had a lot of fun until then. If you are interested in learning new things and exploring new areas in space of ui, resource-managment, model-driven development I can only advice you to take part and learn how to organize, design and implement one of the tools that will have infulence on the next generation of thousands of commercial and none-commercial products.

E4 is more about bringing it to the web

2008-06-05T01:15:00.002+02:00

Since the E4-Presentation at EclipseCon and the SWT-Talk most people think that E4 is only about bringing Eclipse to the web. THAT'S NOT TRUE.

E4 is much more and that SWT gets a web-port is only a small part. Here's my top list of things for E4:

Modeldriven:
One extensible model backing up the whole workbench

DOM: At the moment the Workbench is backed up by ONE model you automatically have a DOM and you can do with this DOM the same you do in Web-Applications (See my prototype)

New Resource Framework:
Making handling resources much more Flexible

New Listener Concept:
The current listener concept in eclipse sucks and makes eclipse slower than it could be

NO SINGLETONS AND STATIC FIELDS

Plugins in NONE-Java: Make it possible to write an Eclipse-Plugin in other languages (JavaScript, ...)

Declarative UI, Easier Styling .... and much more

A radical approach to explore new paths for e4

2008-05-20T07:32:00.020+02:00

After EclipseCon 2008 and the E4 noise I started to rewrite the prototype shown there to use an EMF-Model (I'm going to refer to this prototype in the rest of this posting as PROTOTYPE_1).

It was quite cool to get insights into the platform code and with the code already created for EclipseCon it was not really an achievement to get something running within a fairly short time but finally I wasn't really happy because of multiple things:

I had to work around problems from the beginning to get a workbench up and running

It was hard to add new features because I was limited to things I could find a work-around for or going to learn the complete platform code which would have driven me mad

There was lack of feedback on the real code and we talked more about EMF pros and cons than concentrating on how we want to solve things (I'm still an EMF believer :-)

I asked myself how to solve the following problems:

How can I get up an Workbench-Window without any of the legacy code

How can I easily add features

How can I encourage people to work on E4 without having a deep understanding what's going on inside the current platform. In fact how can I get people outside the Platform-UI-Team to look at the code and understand in an affordable amount of time the concepts behind the workbench and bring up interesting ideas or outline how they think a feature can be implemented

Approximately 1 month ago I sat down and started to define a project which had the following targets:

A workbench with dependency on org.eclipse.jface, org.eclipse.equinox.common, org.eclipse.osgi, org.eclipse.emf

Built around an extensible EMF-Model

NO plugin.xml and NO .exsd (you'll see later how I extend the platform - it's a radical approach I know and looking back it got even more radical then I first thought it's going to be)

Similar but slightly improved EMF-Model compared the original one used to straight port the EclipseCon-Example

Allow multiple instances of the workbench inside one OSGi-Env - no singletons, no static variables!

As few API-Methods as possible (=suppress all the EMF-Methods and adding API-Methods e.g. to attach listeners or traverse the DOM generically) but still strongly typed

provide support for Scripting

Step 1: Redesign The Model From PROTOTYPE_1

I started to redesign the original model and removed some things I didn't like or found they are not needed yet. For example styles/styleclasses now work like they do in a Browser:

.myActiveView {
color: #FF0000;
background-color: #0000FF;
}

<span class="myActiveView" >Green on Blue</span>

where the style-properties and the class-properties are merged. I also moved all UI-Data (Font,Color,Gradient,...) from the UI-Element to the "css"-style definition whether an UI-Element reacts on a style property is the choice of the UI-Element and its implementor.

Step 2: Implementing the Workbench-UI-Core From Scratch

With the .ecore-Definition from Step 1 I created a static workbench.xmi file which defines a model of a static workbench.(Yes I started from a static model you'll see how dynamic such a model gets later). The final source code is ~ 88KB and the resulting .jar 36KB (the model, emf-dependencies are not part of this figures of course). But I think the target is reached I think there's no class having more than 500 Lines of Code (including the comments).
Creating .xmi-Files is a fairly trivial task because EMF comes with a generic editor and I guess people who know GMF could have written a graphical one with in a minute (any GMF-volunteers around?). When this step was finished my XMI-File looked like this

Step 3: Making the model dynamic

When starting Step 3 I first headed of and created .exsd-Files (you can see them here) to contribute the information to my model (views/perspectives). But while doing this I recognized that I'm redefining my .ecore-Model-Elements using .exsd so why the hell do I not provide plugin.xmi-artefacts instead of those plugin.xml files and at runtime create a complete workbench.xmi from all those artefacts. The hard part was to reimplement the loading of xmi-File (or rather to identify the source-code where the plugin.xml is processed to copy the logic). This left me with 3 files

workbench.xmi in org.eclipse.e4.workbench.ui

plugin.xmi in org.eclipse.e4.workbench.ui.ide contributing to workbench.xmi

plugin.xmi in org.eclipse.e4.workbench.ui.rhino contributing to plugin.xmi from org.eclipse.e4.workbench.ui.ide

Step 4: Implementing a Scritable-DOM

So now I had a workbench-model constructed at runtime using XMI-Artefacts. Doing some cool UI-Stuff was the next on my list. Wraping up an EObject as an Object-Scritable for Rhino was something I had already written for PROTOTYPE_1 so I "stole" the code from myself. The top feature on my list was to move a View (in 3.3 a ViewPart) in the model and automatically update the UI. So I wrote a view which presented the current workbench model inside a TreeViewer and allowed me to drag a view from stack to stack. It wasn't really is to distinguish a move from a remove but with help from Ed I managed to get it working. See the screen cast at the end of this posting.

Step 5: Persisting the current workbench state

So I was able to drag around the views but everytime I shut down the workbench and restarted model was recreated from the artifacts and started in the initial state. So adding persistance was next the next "big" issue. Well there's nothing more to say than these lines of code:


if (!restore) {
uri = URI.createPlatformPluginURI(
       "/org.eclipse.e4.workbench.ui/META-INF/EWorkbench.xmi",true);
} else {
uri = URI.createFileURI(restoreFile);
}

// Save
try {
((EObject)workbench).eResource().save(null);
} catch (IOException e) {
e.printStackTrace();
}

Step 6: Extending the extension

Haven't you ever dreamed of extending an extension. I decided that my WorkbenchStructureViewPart should restore the current selection when coming up from a restored state but my generic model-element I contribute didn't had a slot to restore the information. So I digged into and searched how EMF allows me to extend an existing element (in fact once more Ed pointed me in the right direction). Now the plugin.xmi contributed by org.eclipse.e4.workbench.ui.rhino looks like this.

Step 7: Multiple Instances of the workbench

Not using org.eclipse.ui, no singletons and static variables automatically allows to have multiple workbench instances running. So in theory making this workbench run on top of the RAP framework should be possible without patching any code parts.

Acknowledgement / A Screencast / How to get it run

Before I forget about it two other guys (Boris and Ed) provided ideas, code and input to those freaking lines of code available from Eclipse-CVS using this ProjectSet.

Finally I created a Screencast for you to look at (it's a bit big (15MB) because I have no idea how to do Screencasting with OSS-Software on OS-X).

You'll see that I radically stripped down everything and made some strange decisions (e.g. no plugin.xml), backwards compatibility is not addressed at all, ... . Whether you like the idea of contributing XMI-Artefacts instead of .exsd & plugin.xml is not the question. The interesting thing IMHO is that it takes so few lines of code to show a nice workbench backed up by a model and reacting on (structural-)changes inside of it.

Eclipse E4 and UFacekit

2008-03-20T22:13:00.006+01:00

E4 and my impression

Haveing attended the E4 Talk, A Future of SWT and the E4 BOF. I'm looking forward for a lot of innovation and discussion about new architectures at various levels of the Eclipse-Platform.

The most important thing to notice is that E4 is much more than simply bringing RCP to the webspace. Still I'm going to concentrate on the UI-Aspect of E4 in the rest of the post.

There's never been a better time to start getting involved because I myself (or you yourself) can to some extend define how the future looks like.

From the discussion I had with all the guys from the Platform/SWT/...-team I feel fairly comfortable infact I'm glad the Platform/SWT-Team recognized that RAP is not the only solution to get RCP-Applications run inside the browsers. The current SWT-prototype code uses established technologies like GWT, Dojo. In fact with the current prototype design SWT is going to be for DOJO what GWT-Ext/MyGWT are for Ext-Js nowadays.

UFacekit and E4

Do we still have to put effort into UFacekit?

When I first saw what's been done by the E4-Prototypers my first reaction was: Do we still need to work UFacekit? My answer is definately YES because UFacekite is more than providing a possibility to run your Desktop-UI inside a Browser. UFacekit has more to offer than a uniform Widget-API. UFacekit provides other values:

Eclipse-Core-Databinding compatible to GWT

Eclipse-EMF-Ecore compatible to GWT

Highlevel-Abstraction for Eclipse-Databinding

Easy support for Decoration, ...

... and much more

If SWT for Browser is getting reality (and it will trust me) people will want to use all this stuff in their application and then UFace provides them with all they need.

How can UFacekit profit

Well we get a first class Browser-Widget implementation for free or even better we can take part to make this happen (I'm willing get part of this effort) and use it in UFacekit.

UFacekit News

I added an Example how to use EMF + UFacekit inside GWT.
You can take a look at the code here.

Angelo started to add CSS-Support for SWT-Widget in his own project and offered to donate it to UFacekit but I didn't had time to take look how to use it in UFacekit until now

Work on GWT-Ext port continues but getting the layout stuff right is a real pain

UFace - Update

2008-03-06T21:01:00.006+01:00

I recognized today that I haven't blogged about one of my favorite OSS-project (UFace/UFacekit) lately.

For those of you who have never heard of this project let me introduce it in a few sentences.

UFace or UFacekit has the following targets:

Add a highlevel API above Eclipse-Databinding

Helping Eclipse-Databinding to gain momentum outside Eclipse/SWT/JFace world by providing Observable-Implementation for various UI-Toolkits like Swing, GWT, ...

Helping OSGi to be used in UI-Applications outside Eclipse-RCP e.g. in Swing Applications

Providing a uniform UI-API for all those widget-systems including builders for common form layouts (e.g. 2 column label/field list)

We have been fairly busy lately and added the following things into UFace:

Validation and Decoration Support (contributed by Kenneth Westelinck) for Swing and SWT

Worked heavily on the MyGWT integration

Maven-Build-System

Validation and Decoration

Adding decorations to a UIForms (our abstraction above the databindingContext providing a uniform API for different Databinding-Implementations JavaBean/EMF/UBean/...) is not more than adding these 2 lines to your sources:

StatusDecoratingInterceptor interceptor = 
       new StatusDecoratingInterceptor(detailComposite);
detailForm_1.setAfterBindInterceptor(interceptor);

Darn cool, isn't it?

The resulting UI with validation error looks like this:

SWT on Win32:

Swing on Win32:

UFacekit implementation for MyGWT

Beside providing a higherlevel API above Eclipse-Databinding the other idea of UFace is to provide a uniform API to deploy your applications in different ways (Desktop, Web, Mobile-Devices, ...). In Web-Space we decided to go the GWT way which means your application is running completely in the browser and only business data is fetched from the server.

This concept is different from the one of RAP who, as far as I have understood the framework, does most of the work on the server-side and uses the browser "only" for rendering purposes (RAP devs please correct if I'm wrong here).

The hardest thing to bring to browsers are SWT-Layouts and that's where I'm currently progressing slowly but steadily at the moment. This is how the the same form looks like in the browser rendered with MyGWT:

It's not 100% right and Combo and List aren't working either but it was quite an achievement to get that far.

Current status / Release plans

My first draft plan was to have an M1-Milestone for JFace, Swing and MyGWT implementation ready for EclipseCon but I had to delay this because my current work load hasn't give me enough time to work on UFacekit too many hours. Today JFace and Swing are complete (as complete a first Milestone can be) and only MyGWT is missing so I hope we could have a first Milestone by April.

What's in the queue

We already have a queue for features we'd like to integrate (an incomplete list is this):

Support for more Widgets Tree/TreeTable, TabFolders, ...

Implementation ontop of Eclipse-Forms

Better looking decorations on Swing

Support for CSS to style your widgets

Extensible converts

EMF + Databinding - I'm adicted to this stuff

2008-01-23T13:42:00.000+01:00

Ed blogged somedays ago about the progress he made makeing EMF available to RAP and J2ME and there are more and more people requesting a simple example project where some EMF-Databinding-Features are shown.

I've already send some code to the EMF-newsgroup and today I've added some more bits showing how to bind a Detail-List.

I'm going to add some more interesting stuff (e.g. field-dependencies, validation, ...) when I have time and will restart working on my article on EMF+Databinding+RCP+iBatis.

If you want to take a look at source code you can grab it from here.

There are some issues you need to be aware of when it comes to
e.g. Master-Detail + Field-Dependencies.

This is where UFace comes into play which handles this kind of thing for you (and even more).

Because I'm talking about UFace. We are making progress since the last blog entry the following things have happend:

refactored Factory-API to get extensible and not cluttered with overloaded methods

started to think how UForm can be used by native implementators (UForm is an abstraction level above Databinding and your Model-Implementation-Technology)

we added a new committer just today (Angelo Zerr) who develops some cool XML-UI things (See Akrogen) and is enhancing our Swing-Binding and SWT-Bindings. Welcome Angelo.

Set up a Committer and Contributor policy. I hate this legal stuff and we want to keep it at minimum but this has to be the foundation of every project

Received a code donation (SWT GridLayout for Swing) from Daniel Spiewak (See Daniels Code contribution)

One month of UFacekit-Development

2008-01-10T21:05:00.000+01:00

A month ago James Strachan and I started hacking on a project we named UFacekit.

We both faced the need to write datacentric applications for different deployment environments (Desktop (Swing/SWT), GWT (MyGWT/GWT-Ext), ...) and we thought there must be an easy and fast way to come up with something that makes our day job easier. At this very moment UFacekit was born.

There are different things we are targeting with the project.

Provide a uniform Facade above widget implementations (SWT,Swing,GWT,...)

Promote the use of Eclipse-Databinding (and other related technologies e.g. EMF) outside Eclipse-World (Swing,GWT, ...) and provide a highlevel API above the low-level databinding API

Provide reuseable Bundles which can be used independently
- you are only interested in Swing-Databinding but still want to use the native Swing-API? - UFacekit provides an indepented Swing-Observable bundle for you
- you want to use an alternative Bean-like implementation not relying on reflection and EMF is too heavy for you? - UFacekit provides an independent implementation for you named UBean

Instead of writing an SWT-Port for GWT/Swing (I know for Swing there's already an SWT port) we decided to go the Facade/Factory way and started hacking and the progress we made in this very short period of time (we are only working on it in the evening) is more than amazing.

Take a look at the following Screenshots they show what's already possible with the current sources.

They look fairly identical (the only reason they not look completely the same is that I haven't ported the GridLayout from SWT to Swing but relying on Mig-Layout).

They are full of features you need many lines code without a framework doing the nifity bits for you (e.g. MasterDetail + Field-Dependencies):

Master-Detail support

Model-UI-Binding

Field-Dependencies (Country/Federalstate)

Setting up this UI needs:

~ 80 Lines of Widget-Toolkit-Independent code

~ 20 Lines of Widget-Dependent code (= the start of the application which is currently not abstracted)

The amazing thing is that both UIs are made up by the same source code:


    public void createFormUI(UIComposite root) {
        UIFactory ui = root.getFactory();

        UBeanForm listForm = new UBeanForm();
        final UBeanForm detailForm_1 = new UBeanForm();

        UIComposite containerComposite = ui.newComposite(root, null, ui.newGridLayout(2));

        TableColumn[] columns = {
                new TableColumn("People", new NameLabelProvider())
        };

        UITable table = ui.newTable(listForm, containerComposite, new GridLayoutData(200, GridLayoutData.DEFAULT, GridLayoutData.ALIGN_BEGINNING, GridLayoutData.ALIGN_FILL, false, true), listForm.detailList(AddressBook.PEOPLE, Collection.class), columns);

        // ---------------------

        UIComposite detailComposite = ui.newComposite(containerComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, true), ui.newGridLayout(2));
        ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_CENTER), "ID");
        ui.newTextField(detailForm_1, detailComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, false), detailForm_1.detailValue(Person.ID, int.class));

        ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_CENTER), "Name");
        ui.newTextField(detailForm_1, detailComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, false), detailForm_1.detailValue(Person.NAME, String.class));

        ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_CENTER), "Location");
        ui.newTextArea(detailForm_1, detailComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, false), detailForm_1.detailValue(Person.LOCATION, String.class));

        ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_CENTER), "Country");
        UICombo combo = ui.newCombo(detailForm_1, detailComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, false), detailForm_1.detailValue(Person.COUNTRY, Country.class), ModelHelper.createWritableList(getModel().getCountries(), Country.class), new CountryLabelProvider());

        ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_BEGINNING), "Federalstate");
        ui.newDependentListBox(detailForm_1, detailComposite, new GridLayoutData(GridLayoutData.DEFAULT,120,GridLayoutData.ALIGN_FILL, GridLayoutData.ALIGN_FILL, true, false), detailForm_1.detailValue(Person.FEDERAL_STATE, FederalState.class), (IObservableList) detailForm_1.detailList(Country.FEDERAL_STATES, Collection.class).createObservable(combo.getSelectionObservable()), new FederalStateLabelProvider());

        WritableValue value = ModelHelper.createWritableValue(getModel());
        listForm.bind(value);

        IObservableValue detailObservable = table.getSelectionObservable();
        detailForm_1.bind(detailObservable);

        UBeanForm detailForm_2 = new UBeanForm();

        columns = new TableColumn[] {
          new TableColumn("ID", new IDLabelProvider()),
                new TableColumn("Name", new NameLabelProvider()),
                new TableColumn("Location", new LocationLabelProvider())
        };

        ui.newLabel(detailComposite, new GridLayoutData(GridLayoutData.ALIGN_END, GridLayoutData.ALIGN_CENTER), "");
        ui.newTable(detailForm_2, detailComposite, new GridLayoutData(GridLayoutData.ALIGN_FILL,GridLayoutData.ALIGN_FILL,true,true), detailForm_2.detailList(Person.FRIENDS, Collection.class), columns);
        detailForm_2.bind(detailObservable);
    }

  public void run(final String uiMethod) {
  Display display = new Display();

  Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {
    public void run() {
      Shell shell = createUI(uiMethod);
      shell.setSize(650, 500);
      shell.setText("UFacekit - JFace-Demo ");
      Display display = Display.getCurrent();
        while (!shell.isDisposed()) {
          if (!display.readAndDispatch()) {
            display.sleep();
          }
        }
      }
    });
  }

  private Shell createUI(String uiMethod) {
    final Shell shell = new Shell();
    SWTComposite composite = new SWTComposite(shell,new JFaceFactory().newFillLayout());
    // generic code as shown above

You can even more reduce the size and complexity of the source by using FormBuilder-classes we are going to provide to make creating standard-forms like this as simple as possible.

Before we are publishing a first cut we need to finish the GWT-implementation (GWT/MyGWT/GWT-Ext) but we (in this case James) are on a good way and we should have a release fairly soon. Naturally there are some gaps (e.g. missing widgets, API inconsistencies) but hey the project just got 1 month so I hope you don't mind.

Did this spot your interest? Come and join our google group and share your ideas with us.

EclipseCon: I'll be there

2008-01-05T13:23:00.000+01:00

News 1:

Just booked my flight and my room at the Hyatt. I'm excited to meet you all.

There are so many interesting talks like Steve's talk about the future of SWT which I'm very interested in because recently the Web-2.0 movement hit me hard and I've started to make Eclipse-Core-Technologies available in Web-Env.

News 2:

The other news I'd like to share with we you is that together with James Strachan I started a fairly interesting "experiment" called UFaceKit.

In short the project aims to provide a facade above widget implementations to use a uniform API above various Java-Widget implementations to create Datacentric-Applications.

Beside providing this generic API the project is split into many individual plugins/bundles which can be used out of the uface-scope:

A light weight JavaBean like implementation useable without any reflection-API the implementation is called UBean

Observables for UBean like Eclipse provides an implementation for JavaBeans

UI-Observables for GWT/MyGWT/GWT-EXT

UI-Observables for Swing

As you see one of the "waste products" of this project is that Eclipse-Databinding is can be used by Swing/GWT/... developers.

If you are interested in the project take a look at our project page and join the google-group. We are in pre-alpha stage and code changes a lot but we appreciate your help e.g. to provide an implementation for other Java-UI toolkits (QT-Jambi, Android, ...), help us with the Swing, GWT implementations of course all code is released under EPL.

Primary targets currently are:

SWT/JFace

GWT-implementations

ed4g - Eclipse Databinding for GWT-Widgets 0.0.1

2007-12-06T00:20:00.000+01:00

I finally did it. Based upon the plugins I've ported over from Eclipse to compile under GWT I setup a project that provides Observable implementations for GWT and MyGWT widgets but it is open for any other GWT-compatible widget-lib.

A missing thing currently is a 2nd light weight Model-Implementation that works on GWT, I thought about simply providing an Observable implemented ontop of a HashMap. EMF is available and working but I'd like to have a second very light weight implementation which can be used by people not familiar with EMF and only need some GWT related binding.

You can find the project here.

EMF + Databinding + GWT 1.5 - it works

2007-11-19T02:23:00.000+01:00

Since the last time I blogged about the on going work to provide Eclipse-Core-Features for users of GWT some time has elapsed so I thought I should give you an update.

Ed and Boris jumped on the train and try to help me with their indepth knowledge of EMF and Databinding. It's great to have them on board.

Today I managed the first time to use EMF-Core-Modules (EMF-Common und EMF-Ecore) in a GWT-context. There are some rough edges and not everything is working but it's amazing that the newly developed EMF-Databinding-Integration developed in Bug 75625 works nearly out-of-the box.

My GWT-Code looks like this now:


EMFDataBindingContext ctx = new EMFDataBindingContext();

targetObservableValue = GWTObservables.observeText(
   textBox, GWTObservables.Change);

modelObservableValue = EMFObservables.observeDetailValue(
   Realm.getDefault(),
   value, 
   BrojectPackage.Literals.PROJECT__NAME);

IConstants.BINDING_BUILDER.bindTextValue(
   ctx, 
   targetObservableValue, 
   modelObservableValue);

I've started an example project you can look at Broject and get the sources from my svn-repository, it's in a very very early stage but you should get the idea.

If you are interested in the work then you should subscribe to the following bugs EMF-Common, EMF-Ecore, Extension to GWT-JRE-Emulation, Core-Databinding.

More details about Databinding and GWT

2007-10-09T13:48:00.000+02:00

I promised in the morning that I'll blog more details about giving GWT-Developers access to concepts provided by Eclipse.

Currently my port provides:
- Core-Databinding + PEMF-Observables (for standard values (no lists at the moment))
- Support for Perspectives (untested but available in code)
- ViewPart-Implementation
- Access to the low-level-bits of the Command-framework (AbstractHandler and friends)
- A first draft implementation of ExtensionPointRegistry

This is currently not a straight port and the API is in some situations different but I'll resolve this later on.

Maybe some code example help you to understand the idea behind my work.

Starting up the application:


public class DemoApplication extends Plugin {

 /**
  * This is the entry point method.
  */
 public void start() {
  super.start();
  Workbench.createAndRunWorkbench(new WorkbenchAdvisor());
 }

 public String getPluginXML() {
    return
"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"+
"<?eclipse version=\"3.2\"?>\n"+
"<plugin>\n"+
"    <extension\n"+
"          point=\"org.eclipse.ui.views\">\n"+
"       <view\n"+
"             name=\"Range of Product\"\n"+
"             allowMultiple=\"false\"\n"+
"             class=\"at.bestsolution.gwt.demo.client.ui.views.ProductRangeViewPart\"\n"+
"             id=\""+IConstants.PRODUCT_RANGE_VIEW_PART+"\">\n"+
"       </view>\n"+
"       <view\n"+
"             name=\"Product\"\n"+
"             allowMultiple=\"true\"\n"+
"             class=\"at.bestsolution.gwt.demo.client.ui.views.ProductEditingViewPart\"\n"+
"             id=\""+IConstants.PRODUCT_EDITING_VIEW_PART+"\">\n"+
"       </view>\n"+
"    </extension>\n"+
"</plugin>\n"
;
 }

 public String getPluginName() {
  return "at.bestsolution.gwt.demo";
 }

Setting up a TreeViewer:


public Widget createPartControl() {

    VerticalPanel panel = new VerticalPanel();
    panel.setSize("100%", "100%");
    Tree tree = new Tree();
    tree.setSize("100%", "100%");
    panel.add(tree);
    panel.setCellHeight(tree, "100%");
    panel.setCellWidth(tree, "100%");

    final TreeViewer viewer = new TreeViewer(tree);
    viewer.setContentProvider(new TreeContentProvider());
    viewer.setLabelProvider(new LabelProvider());
    viewer.setInput(Datasource.getDatasource().getProductRange());
    viewer.addSelectionChangedListener(new SelectionChangedListener());
    getSite().setSelectionProvider(viewer);
// ...

And finally binding a control to a model element:


TextBox box = new TextBox();
box.setEnabled(false);
table.setWidget(0, 1, box);

IObservableValue targetObservableValue = GWTObservables.observeText(box, GWTObservables.Change);
IObservableValue modelObservableValue = PEMFObservablesFactory.observeValue(Realm.getDefault(), product, Product.ID);
UpdateValueStrategy targetToModel = new UpdateValueStrategy();
UpdateValueStrategy modelToTarget = new UpdateValueStrategy();
modelToTarget.setConverter(new IntegerToStringConverter());
ctx.bindValue(targetObservableValue, modelObservableValue, targetToModel, modelToTarget);

The final result looks like this:

Doing RCP-Like programming with GWT

2007-10-09T07:43:00.000+02:00

After having spent some time on GWT + Databinding I can now report success on porting over the Core-Databinding framework to GWT with fairly no changes from what is found in the Eclipse-CVS-Repository.

But to do real programming in GWT there's more you need (Views, Editors, Commands, Actions, ...) so I've also taken over the other core ideas from Eclipse into a GWT-Lib I called gjface (it isn't a straight port of the Eclipse-API currently because of the lack of time but it's fairly usebable already).

I've also created a Demo-Application you can find here and if you are interested how this Application is created you can get the source from here. I have only tested it on Firefox so it might be that it's not working on IE currently.

I'll blog later today how this all works together but if you want to take an in depth look I'm at ESE!

The marriage of GWT with Eclipse-Technologies

2007-09-29T00:17:00.000+02:00

I'm currently on the track to explore GWT and started just this morning with it. The first thing I found missing is something like the Viewers-Concept from JFace.

I don't want to learn new things if the one I'm familiar with would make my life much easier. JFace-Viewers is one of my main working areas in Eclipse-land. So I sat down and took a closer look and after 1 hour of work my GWT-code looks like this:


package at.bestsolution.eclipse.jface.example.client;

import java.util.ArrayList;

import org.gwtwidgets.client.util.SimpleDateParser;

import at.bestsolution.eclipse.jface.client.viewers.TreeViewer;
import at.bestsolution.eclipse.jface.example.client.model.Family;
import at.bestsolution.eclipse.jface.example.client.model.Person;
import at.bestsolution.eclipse.jface.example.client.ui.MyContentProvider;
import at.bestsolution.eclipse.jface.example.client.ui.MyLabelProvider;

import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.ui.RootPanel;
import com.google.gwt.user.client.ui.Tree;

/**
 * Entry point classes define onModuleLoad().
 */
public class JFaceExampleApp implements EntryPoint {

  /**
   * This is the entry point method.
   */
  public void onModuleLoad() {

   Tree tree = new Tree();
   TreeViewer viewer = new TreeViewer(tree);
   viewer.setLabelProvider(new MyLabelProvider());
   viewer.setContentProvider(new MyContentProvider());
   viewer.setInput(createInput());

   RootPanel.get().add(tree);
  }

  private ArrayList createInput() {
   SimpleDateParser parser = new SimpleDateParser("yyyy-MM-dd");
   ArrayList list = new ArrayList();

   Family fam = new Family("Schindl");
   Person p = new Person("Tom",parser.parse("1979-05-01"),fam);
   p = new Person("Tina",parser.parse("1980-10-14"),fam);
   p = new Person("Laura",parser.parse("1991-08-07"),fam);

   list.add(fam);

   fam = new Family("Hoppichler");
   p = new Person("Andreas",parser.parse("1977-11-06"),fam);
   p = new Person("Franzi",parser.parse("1978-11-02"),fam);

   list.add(fam);

   return list;
  }
}

And the respective Viewer-classes like this:


package at.bestsolution.eclipse.jface.example.client.ui;

import java.util.ArrayList;

import at.bestsolution.eclipse.jface.client.viewers.ITreeContentProvider;
import at.bestsolution.eclipse.jface.client.viewers.Viewer;
import at.bestsolution.eclipse.jface.example.client.model.Family;
import at.bestsolution.eclipse.jface.example.client.model.Person;

public class MyContentProvider implements ITreeContentProvider {

 public Object[] getChildren(Object parentElement) {
  if( parentElement instanceof Family ) {
   return ((Family)parentElement).getList().toArray();
  }
  return new Object[0];
 }

 public Object getParent(Object element) {
  if( element instanceof Person ) {
   return ((Person)element).getFamily();
  }

  return null;
 }

 public boolean hasChildren(Object element) {
  return getChildren(element).length > 0;
 }

 public Object[] getElements(Object inputElement) {
  return ((ArrayList)inputElement).toArray();
 }

 public void dispose() {

 }

 public void inputChanged(Viewer viewer, Object oldInput, Object newInput) {

 }

}


package at.bestsolution.eclipse.jface.example.client.ui;

import org.gwtwidgets.client.util.SimpleDateFormat;

import at.bestsolution.eclipse.jface.client.viewers.ILabelProvider;
import at.bestsolution.eclipse.jface.example.client.model.Family;
import at.bestsolution.eclipse.jface.example.client.model.Person;

public class MyLabelProvider implements ILabelProvider {
 private SimpleDateFormat format = new SimpleDateFormat("dd.MM.yyyy");

 public String getText(Object element) {
  if( element instanceof Family ) {
   return ((Family)element).getName();
  } else if( element instanceof Person ) {
   return ((Person)element).getName() + " ("+format.format(((Person)element).getBirthday())+")";
  }

  return "";
 }

}

Now you think this is cool? Because this was to trivial I thought I'll have to go further and after ~ 6h I had ported the the core-parts from the JFace-Databinding-Framework to GWT! So my UI-Binding-Code looks like this now:


// ....
TextBox box = new TextBox();

TextBoxObservableValue targetValue = new TextBoxObservableValue(box,TextBoxObservableValue.Change);
IObservableValue modelValue = PEMFObservablesFactory.observeDetailValue(Realm.getDefault(), value, "id", String.class);

DataBindingContext ctx = new DataBindingContext();
UpdateValueStrategy targetToModel = new UpdateValueStrategy();
targetToModel.setConverter(new IConverter() {

    public Object convert(Object fromObject) {
        return fromObject.toString();
    }

    public Object getFromType() {
        return null;
    }

    public Object getToType() {
        return null;
    }

});

UpdateValueStrategy modelToTarget = new UpdateValueStrategy();
modelToTarget.setConverter(new IConverter() {

    public Object convert(Object fromObject) {
         return fromObject.toString();
    }

    public Object getFromType() {
        return null;
    }

    public Object getToType() {
        return null;
    }

});
ctx.bindValue(targetValue, modelValue, targetToModel, modelToTarget);

The GWT-Compiler translates all into JS-Code and because there's no Reflection-API available in this space I had to invent my own concept which I lend from EMF hence the name PEMF (for PoorEMF). Without question much of the Databinding-Framework is not working but at this stage I don't mind. The good thing is that all those low-level modules use fairly only classes already available from GWT so porting the whole framework is only a matter of time.

Branding for Windows (How to create .ico files automatically)

2007-06-26T13:41:00.000+02:00

After some time not having developed for Win32. I today had to brand a small RCP-application and once more completely forgot how to create this "Programm Launcher icon" using opensource tools.

So I thought I have to restore this information somewhere I can find it later on:

1. Get nice icons:
The starting point for me is one of the open-source icon-collections (www.icon-king.com/) or oxygen.

2. Boot you favorit Linux Distro (Sorry Win-Users for you this story ends here (or you grab CygWin)):
Install the following tools:

convert: Chances are high it's already installed

icotool: if not installed and not available for your distro (icoutils)

3. Copy the images:
Copy images the images the with the various sizes we need to a directory and given them eaually starting names. In my case these are:

icon_16_16.png

icon_32_32.png

icon_48_48.png

4. Create .ico-File:
The ico-File needed by RCP has to hold 6 images (32bit and 8bit).
So we need to convert the images to 8bit ones:

tom@vinea:icons>

mkdir target

# Workaround because image magick doesn't seem to reduce colors when
# converting from png to png
convert -colors 256 icon_16_16.png target/tmp.gif
convert -colors 256 target/tmp.gif target/icon_16_16_8bit.png

convert -colors 256 icon_32_32.png target/tmp.gif
convert -colors 256 target/tmp.gif target/icon_32_32_8bit.png

convert -colors 256 icon_48_48.png target/tmp.gif
convert -colors 256 target/tmp.gif target/icon_48_48_8bit.png

Copy the original icons over to target-dir:

tom@vinea:icons>
cp -f icon_16_16.png target
cp -f icon_32_32.png target
cp -f icon_48_48.png target

Create the .ico-File using icotool:

tom@vinea:icons>
icotool -c target/icon_16_16_8bit.png target/icon_16_16.png \
target/icon_32_32_8bit.png target/icon_32_32.png \
target/icon_48_48_8bit.png target/icon_48_48.png \
> target/icon.ico

Here's the full script for reference:

#!/bin/sh

rm -rf target
mkdir target

# Workaround because image magick doesn't seem to reduce colors when
# converting from png to png
convert -colors 256 icon_16_16.png target/tmp.gif
convert -colors 256 target/tmp.gif target/icon_16_16_8bit.png

convert -colors 256 icon_32_32.png target/tmp.gif
convert -colors 256 target/tmp.gif target/icon_32_32_8bit.png

convert -colors 256 icon_48_48.png target/tmp.gif
convert -colors 256 target/tmp.gif target/icon_48_48_8bit.png

# Copy images
cp -f icon_16_16.png target
cp -f icon_32_32.png target
cp -f icon_48_48.png target

icotool -c target/icon_16_16_8bit.png target/icon_16_16.png \
target/icon_32_32_8bit.png target/icon_32_32.png \
target/icon_48_48_8bit.png target/icon_48_48.png \
> target/icon.ico

Why do developers need Code-Snippets

2007-06-22T08:59:00.001+02:00

Many of you may already have noticed that we started a Snippet collection for JFace-Elements like the one you know from SWT. Yesterday I updated the wiki-page to show all snippets with a short description.

Are Snippets only something we provide because we love our users soooo much? To me the answer is no.

There are multiple reasons why snippets are a great thing:

Help for users to get started easily (Users)

Useful templates for users to log bugs (Users/Developers)
Without a reproduceable testcase it is very hard to track bugs. Be prepared that JFace-Devs will insist even more on Snippets because now you have starting points to create Snippets easily. Insisting on snippets we often found out that we are not the one to blame but someone different (including the bugreporter itself)

Useful to mark bugs as invalid (Developers)

Useful to check no regressions are introduced (Developers)
We also added snippets to our collection although their Classes are deprecated because this way we had an easy test case that we don't break any backwards contract. In our case we did this for TableTreeViewer

Development example for new features (Developers)
A good example is Snippet026 which was used to develop Cell-Navigation and Editor-Activation throughout the whole 3.3 cycle.

Advertise new API

I'm perFLEXed

2007-06-12T23:29:00.000+02:00

Yesterday Adobe released it's Flex 3 and naturally I went there to see this new cool technology. I downloaded it and got an Eclipse with a GUI-Builder to create SWF-Applications. The nice thing is that Flex uses an XML-Format to store the GUI, ... .

I guess you know what's coming now, don't you? I sat down and looked closer to find out that it would be fairly easy to write a Transformer to convert this in my custom EXSWT-Format used to build SWT/JFace-GUIs. After about 2 hours I now have a minimal XSLT-Stylesheet transforming MXML-Elements (currently mx:label, mx:combo, mx:button) to EXSWT and feeding it into my EXSWT-Lib. The only problem are different heights and widths needed by SWT and SWF but those are minor problems.

Here's the original Flex-Project View one can export as an SWF-Application:

And here the one displayed using SWT-Widgets:

This is only a simple example but it shows how easy it is to define highlevel dialects on top of EXSWT which is a more or less lowlevel XML-Language.

You can as always get the sources from my SVN-Repository and I have once more prepared a .psf-File for all Subclipse users.

Splash-Screen and Threads

2007-06-12T14:29:00.000+02:00

Today I thought it would make my application look much more professional if the login-dialog is part of the splash-screen. The new extension point added in eclipse makes this possible and even provided an template implementation I could use without problem.

The process is straight forward:

Create a Product Configuration (or use your existing one)
Switch to the Splash-Tab
Select in the Customization-Section the Interactive-Template
Switch to the Overview and "Launch an Eclipse application"

You are done. That was easy, wasn't it? To make this work you wouldn't need any help. The tricky thing I faced starts now. In my case I'm authentificating using a database-server and to not block the UI im doing this in a seperate thread and showing a ProgressBar in the mean while.

When the application starts up the splash should look like this:

And while Logging into Database:

So the first action is to add the "Check Login"-Label and the Progress bar like this:


private Label progressLabel;
private ProgressBar progressBar;

/** many lines of code */

private void createProgressInfo() {
    progressLabel = new Label(fCompositeLogin,SWT.NONE);
    progressLabel.setText("Überprüfung läuft");
    GridData data = new GridData();
    data.horizontalIndent = F_LABEL_HORIZONTAL_INDENT - 50;
    progressLabel.setLayoutData(data);
    progressLabel.setVisible(false);
       
    progressBar = new ProgressBar(fCompositeLogin,SWT.NONE|SWT.INDETERMINATE);
    data = new GridData(SWT.NONE, SWT.NONE, false, false);
    data.widthHint = F_TEXT_WIDTH_HINT;
    data.horizontalSpan = 2;
    progressBar.setLayoutData(data);
    progressBar.setVisible(false);
}

private void toggelCheckProgress(boolean state) {
    progressLabel.setVisible(state);
    progressBar.setVisible(state);
    fCompositeLogin.layout();
}

We initially set the those two widgets invisible and show them later when we start the authentification. To make this easy we add helper method to turn the visibility on and off.

The next part is to modify the handleButtonOKWidgetSelected()-method like this:


private volatile int loginStatus = -1;

/** many lines of code */

private void handleButtonOKWidgetSelected() {
    final String username = fTextUsername.getText();
    final String password = fTextPassword.getText();
       
    toggelCheckProgress(true);
       
    Thread t = new Thread() {

        public void run() {
            if( login(username,password) ) {
                loginStatus = 1;
            } else {
                loginStatus = 2;
            }
        }
    }
    t.start();
}

The content of the method is straight forward. It starts a thread and executes a potentially long running task in our case login(String,String). Our task is now to sync back to the gui-thread and:

Proceed with start up (hiding the login details from the splash-screen)
Display Login-Failure to the user

Normally you do this using Display#(a)syncExec() but that's not available in the splash-screen. The work-around I used as you see above is setting a special variable named loginStatus. The trick is now that you add checks for this variable to the Event-Loop method which looks like this afterwards:


private void doEventLoop() {
    Shell splash = getSplash();
    while (fAuthenticated == false) {
        if (splash.getDisplay().readAndDispatch() == false) {
            if( loginStatus == 1 ) {
                loginSuccess();
            } else if( loginStatus == 2 ) {
                loginFailure();
            }
               
            splash.getDisplay().sleep();
        }
    }
}

Your are nearly done now the only two methods missing are:


private void loginSuccess() {
    toggelCheckProgress(false);
    fCompositeLogin.setVisible(false);
    fAuthenticated = true;
    loginStatus = -1;
}
   
private void loginFailure() {
    toggelCheckProgress(false);
    loginStatus = -1;
    MessageDialog.openError(
        getSplash(),
        "Authentification failed",
        "Your username or password was wrong");
}

Well that's all. You are done and have a splash screen who is authenticating without blocking the UI-thread without Display#(a)syncExec. I need to thank Kim for pointing me to this solution and she promised that there will be added API in 3.4 to make this more easier.

Things are evolving

2007-06-09T19:31:00.000+02:00

It's been now a few months I started reworking my the first draft implementation which already provided many interesting things but there was still Java-Code needed to bind-POJOs and to interact with the Datasource.

What's new:

XBL (XmlBindingLanguage) to connect your model with the help of the databinding framework to SWT-Widgets
Switched to work on top of the Eclipse-Command-Framework
Added themeing framework
API cleanup
Refactoring, refactoring

I still see this as a research project which is not useable for production in the near future but if the community likes what I'm doing here these are the next things on my list:

implement INSERT/UPDATE/DELETE on top of the COMMAND-Framework
evolve XBL (new features, refactoring, ...)
Transformer-Framework for EXSWT and XBL (use a highlevel dialect translated to those low-level ones)
Implement new provider which is able to fetch XBL and EXSWT files via HTTP. This would make changing the GUI without the need to redeploy your application to the client (what a cool feature RAP without the Browser :-)
Refactoring, Refactoring, ....

If you are interested you can checkout the current project from my companies SVN-Repository. When using the Subclipse-Plugin I've added you a .psf-File to the project helping you to easily checkout all needed projects from SVN.

New JFace API is in place

2007-03-16T20:16:00.000+01:00

After ~8 months of work we checked in the new JFace-API with many exciting features in to CVS just a few hours ago. To see how powerful this new API is take a look at the this snippet. Test it and report us back problems if there are any.

XSWT, Databinding, ... => DataForms

2007-03-07T22:56:00.000+01:00

It's sometime ago I started rewriting the current XSWT implementation from David Orme. Now I saw the Blog from Alex about Databinding and thought it's time to let you all know that I'm working on a set of plugins which have the following focus:

Use XSWT (or any other Definition Language) to create the GUI
Dynamically link together Forms (Master/Detail, ...) using Eclipse Extension Points
Provide an XML-Dialect to define the binding and data retrieval in XML

Although it's still a long way to go and many many things are not as smooth as they could be but I finally have something to present using a small application.

Here's a screenshot of the small application. Currently you can only add items to it but that's working really fine.

The key point is how this all works technically and what should I say it simply works. There are still about 200 lines of code needed to make this work because the binding has to be done manually at the moment. Go and get the code from our companies SVN-Repository and give me feedback, I've added a projectSet.psf so you can easily check out all needed modules.

The next things I want to address are the following:

Databinding:

Adding missing features (Deletion, ...)

XML-Language for Data-Retrieval and Binding (XBL)
Finishing Event System (= needed for scripting support)

Finalizing/Stabiallizing ExtensionPoints and API

Adding API for a highly Configurable Privileges System
Provide XDOM (= DOM you know from Browsers to easily script Dataforms)

EXSWT:

Transformation Chain (other highlevel dialects transformed to EXSWT which near to SWT/JFace)
Work on XSD-Schema and XML-Editor with Live-Preview
WYSIWYG-Editor

Did I spark your interest? Give me your comments, I know there are other projects around with a fairly similar focus but some of the features are unique to this idea I think but are essential for datacentric applications.

Oh in the end I have had written a design document which is not up-to-date but provide informations where I'm coming from and where I'm going to.

EclipseCon community awards

2007-03-06T09:20:00.000+01:00

I just read the post from Alex about the community awards and couldn't believe finding my name under the ones finally winning the award. Thanks to everybody who voted for me. Now I'm even more disappointed that I couldn't afford attending the eclipse con but maybe I can make it to the Eclipse Summit Europe.

My first commit

2007-03-03T12:25:00.000+01:00

What a great day my first commit to the eclipse cvs-repository. It's a small one patching JavaDoc for a not working API but it's a start. Here's the patch.

TableViewers and Nativelooking Checkboxes

2007-01-26T00:36:00.000+01:00

Many of us have faced the same problem that if you needed to use checkboxes in your TableViewer/TreeViewer they look not native because they are pictures. I had some free minutes and thought that it's time to create a LabelProvider which is able to create platform look-and-feel images out of the box. It's not 100% native but it's not far away. The trick is to automatically create screenshots from CheckBox-Buttons and use them. This way the checkboxes look native on all platforms and correspond to the current look and feel of the platform.

Here's the code if someone is interested:


package at.bestsolution.jface.viewers;

import org.eclipse.jface.resource.JFaceResources;
import org.eclipse.jface.viewers.ColumnLabelProvider;
import org.eclipse.jface.viewers.ColumnViewer;
import org.eclipse.swt.SWT;
import org.eclipse.swt.graphics.GC;
import org.eclipse.swt.graphics.Image;
import org.eclipse.swt.graphics.Point;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Shell;

public abstract class EmulatedNativeCheckBoxLabelProvider 
  extends ColumnLabelProvider 
{
  private static final String CHECKED_KEY = "CHECKED";
  private static final String UNCHECK_KEY = "UNCHECKED";
 
  public EmulatedNativeCheckBoxLabelProvider(ColumnViewer viewer) {
    if( JFaceResources.getImageRegistry().getDescriptor(CHECKED_KEY) == null ) {
      JFaceResources.getImageRegistry().put(UNCHECK_KEY, 
        makeShot(viewer.getControl().getShell(),false));
      JFaceResources.getImageRegistry().put(CHECKED_KEY,
        makeShot(viewer.getControl().getShell(),true));
    }
  }
 
  private Image makeShot(Shell shell, boolean type) {
    Shell s = new Shell(shell,SWT.NO_TRIM);
    Button b = new Button(s,SWT.CHECK);
    b.setSelection(type);
    Point bsize = b.computeSize(SWT.DEFAULT, SWT.DEFAULT);
    b.setSize(bsize);
    b.setLocation(0, 0);
    s.setSize(bsize);
    s.open();

    GC gc = new GC(b);
    Image image = new Image(shell.getDisplay(), bsize.x, bsize.y);
    gc.copyArea(image, 0, 0);
    gc.dispose();
    
    s.close();
    
    return image;
  }

  public Image getImage(Object element) {
    if( isChecked(element) ) {
      return JFaceResources.getImageRegistry().
               getDescriptor(CHECKED_KEY).createImage();
    } else {
      return JFaceResources.getImageRegistry().
               getDescriptor(UNCHECK_KEY).createImage();
    }
  }

  protected abstract boolean isChecked(Object element);
}

I haven't really tested this (currently only on WinXP) but I suppose it's working on all platforms. You can also get the code from my svn-repository which holds some other interesting utilities and viewer classes.

The new faces of JFace (part2)

2007-01-18T22:42:00.000+01:00

The last time I showed you the new programming model we introduced to JFace to make it feel like programming SWT.

But has this been the only reason that we decided to add this new API beside the existing one (ILabelProvider, ITableLabelProvider, IColorProvider, ITableColorProvider, IFontProvider, ITableFontProvider) .
Sure enough it was not the only reason. First of all many newcomers have been confused by all those NON MANDATORY interfaces to control different aspects of items and we faced the problem that whenever SWT-Provided a new feature e.g. Owner Draw Support in 3.2 we would have to add a new interface type and to support new features e.g. ToolTip support for table/tree cells we also had to provide a new interface. We decided that this is not the way to go for the future.

So we sat down and thought about a complete new structure below JFace tree and table support. We added the idea of rows (ViewerRow) and cells (ViewerCell) abstracting common things provided of TreeItem and TableItem and completely hiding the widget specific things into this class. The abstraction level this provided to us made it possible to provide a common class named ColumnViewer.

So what have we learned so far:

We don't need all those interfaces any more
We have a new abstraction level for column based viewers (ViewerRow, ViewerCell)
We have a new base class named ColumnViewer

So you may ask what you should use if you can't use the old interfaces any more. Well the answer is ColumnLabelProvider or if you want to implement the whole cell behaviour your own it's abstract base class named CellLabelProvider. The new ColumnLabelProvider combines all currently know interfaces (ILabelProvider, IFontProvider, IColorProvider). There's no base class visible to you supporting ITable*-interfaces because those interface put limitations to tables I'll show you later let's now explore how to use the new ColumnLabelProvider interface and how it is used.


TableViewer viewer = new TableViewer(parent,SWT.FULL_SELECTION);

TableViewerColumn column = new TableViewerColumn(viewer,SWT.NONE);
column.setLabelProvider(new StockNameProvider());
column.getColumn().setText("Name");

TableViewerColumn column = new TableViewerColumn(viewer,SWT.NONE);
column.setLabelProvider(new StockValueProvider());
column.getColumn().setText("Modification");

public class StockNameProvider extends ColumnLableProvider {
 @Override
 public String getText(Object element) {
    return ((Stock)element).name;
 }
}

public class StockValueProvider extends ColumnLabelProvider {

 @Override
 public String getText(Object element) {
    return ((Stock)element).modification.doubleValue() + "%";
 }

 @Override
 public Color getForeground(Object element) {
    if( ((Stock)element)modiciation.doubleValue() < 0 ) {
        return getDisplay().getSystemColor(SWT.COLOR_RED);
    } else {
        return getDisplay().getSystemColor(SWT.COLOR_GREEN);
    }
 }
}

You may now argue that this was easier with the old ITable*-API and you are true but from the point of reusability this version is much more flexible and you can reuse your LabelProviders for many different TableViewers because they don't hold any index informations. Another thing is that you needed a bunch of custom code if you wanted the columns to be reordable with the old API this is not an issue any more with the new API because the LabelProvider is directly connected to the column and moves with it.

Next time I'll continue with some nice new LabelProvider features like ToolTip support and OwnerDraw.

What items are visible in Table/Tree?

2007-01-05T11:15:00.000+01:00

Have you often asked yourself which items are visibile in Table/Tree. Maybe you need these informations to dispose system-resources (e.g. if you have different images in every row you can easily run out of system resources).

What to do? There's no SWT-API available to calculate this information. So we need a bunch of custom code to make this work. The following codefragements are only a first rough test case and they need JFace from 3.3M4 and a patch from bug 151295 .

Step 1: Setup the infrastructure
- Event object to inform consumers about the change of visible rows

public class ViewerRowStateChangedEvent extends EventObject {
 private static final long serialVersionUID = 1L;

 public ArrayList itemsHidden;

 public ArrayList itemsVisible;

 public ViewerRowStateChangedEvent(Object source) {
   super(source);
 }
}

- ViewerRowStateChangeListener for consumers to implement

public interface ViewerRowStateChangeListener {
 public void itemStateChangedListener(ViewerRowStateChangedEvent event);
}

Step 2: Create an AbstractClass implementing the visible row logic on base of ViewerRow and the new API whichn will hopefully added by bug 151295.

public abstract class AbstractViewerRowVisibilityStateSupport {
 private ArrayList currentItems = new ArrayList();

 private ColumnViewer columnViewer;

 private ListenerList listenerList = new ListenerList();
 
 public AbstractViewerRowVisibilityStateSupport(ColumnViewer columnViewer) {
   this.columnViewer = columnViewer;
  
   Listener l = new Listener() {
     public void handleEvent(Event event) {
       ArrayList list = recalculateVisibleItems();
       ArrayList itemsVisible = new ArrayList();

       Iterator it = list.iterator();
       Object obj;

       while( it.hasNext() ) {
         obj = it.next();

         if( ! currentItems.remove(obj) ) {
           itemsVisible.add(obj);
         }
       }

       ArrayList hiddenItems = currentItems;
       currentItems = list;

       if( itemsVisible.size() > 0 || hiddenItems.size() > 0 ) {
         if( ! listenerList.isEmpty() ) {
           ColumnViewer v;
           v = AbstractViewerRowVisibilityStateSupport.this.columnViewer;

           ViewerRowStateChangedEvent ev = new ViewerRowStateChangedEvent(v);
     ev.itemsHidden = hiddenItems;
     ev.itemsVisible = itemsVisible;

           Object[] listeners = listenerList.getListeners();
           ViewerRowStateChangeListener l;
 
     for( int i = 0; i < listeners.length; i++ ) {
             l = (ViewerRowStateChangeListener)listeners[i];
       l.itemStateChangedListener(ev);
     }
         }
       }     
     }
   };
   addListeners(getControl(),l);
 }

 protected abstract void addListeners(Scrollable control, Listener l);

 protected abstract ViewerRow getTopRow();

 protected Scrollable getControl() {
   return (Scrollable)columnViewer.getControl();
 }

 public void addItemStateListener(ViewerRowStateChangeListener listener) {
   listenerList.add(listener);
 }

 private ArrayList recalculateVisibleItems() {
   ArrayList list = new ArrayList(100);
   ViewerRow topRow = getTopRow();

   if( topRow != null ) {
     int totalHeight = getControl().getClientArea().height;
     int itemHeight = topRow.getBounds().height;

     list.add(topRow);

     int tmp = topRow.getBounds().x+itemHeight;
     // tmp += itemHeight;
     // this would be more precise but half rows
     // would be marked as non-visible
   
     // run until we reached the end of the client-area
     while( tmp < totalHeight ) {
       tmp += itemHeight;
       topRow = topRow.getNeighbor(ViewerRow.BELOW, false);

       if( topRow == null ) {
         break;
       }

       list.add(topRow);
     }
   }

   return list;
 }
}

We simply listen to events who can change the items shown in the Scrollable make a diff to the last state and inform all consumers about the change.

But what are the events how modify the items shown? This is delegated to specialized classes for Table and Tree because those may differ from control to control.

Step 3: Provide specialized implementation for Tree and Table
- An implementation for SWT-Table

public class TableViewerRowVisibilityStateSupport extends
     AbstractViewerRowVisibilityStateSupport {
 public TableViewerRowVisibilityStateSupport(TableViewer columnViewer) {
   super(columnViewer);
 }

 protected void addListeners(Scrollable control, Listener l) {
   control.getVerticalBar().addListener(SWT.Selection, l);
   control.addListener(SWT.Resize, l);
   control.addListener(SWT.KeyUp, l);
 }

 protected ViewerRow getTopRow() {
   Table t = (Table)getControl();
   int index = t.getTopIndex();
   TableItem topItem = t.getItem(index);
  
   if( topItem != null ) {
     return (ViewerRow) topItem.getData(ViewerRow.ROWPART_KEY);
   }

   return null;
 }
}

- An implementation for SWT-Tree

public class TreeViewerRowVisibilityStateSupport extends
     AbstractViewerRowVisibilityStateSupport {
 public TreeViewerRowVisibilityStateSupport(TreeViewer columnViewer) {
   super(columnViewer);
 }

 protected void addListeners(Scrollable control, Listener l) {
   control.getVerticalBar().addListener(SWT.Selection, l);
   control.addListener(SWT.Resize, l);
   control.addListener(SWT.MouseUp, l);
   control.addListener(SWT.KeyUp, l);
 }

 protected ViewerRow getTopRow() {
   TreeItem topItem = ((Tree)getControl()).getTopItem();
   if( topItem != null ) {
     return (ViewerRow) topItem.getData(ViewerRow.ROWPART_KEY);
   }
   return null;
 }
}

As said this is very rough first draft how this could work. I'll post this got some coments about possible issues this could provoke.

the new Faces of JFace (part 1)

2006-12-06T16:30:00.000+01:00

Some of you may have noticed JFace provides new API to streamline JFace usage and to support new features like:

custom owner draw
tooltips for tree/table-cells
keyboard editing support for viewers

To provide all those new features we (Tod Creasey, Boris Bokowski and me) decide to refactor the underling JFace code, provide new classes and to move things from specialized classes to more generice ones. The central of the whole refactoring brought up a whole bunch of new classes where the most important are the following:

ColumnViewer: Provides all things common to Viewers who deal with the concept of columns and rows
ViewerRow: Represents a row in the column viewer and wraps TableItem and TreeItem from SWT
ViewerCell: Represents one cell in the table/tree

We decide to create those new classe because it gives us the possibility to push as much code in the widget independent ColumnViewer instead of the widget centric classes derived from it.

All the changes mentionned above might not be interesting to you because most of the time you want use them directly so let's take a look at the more interesting things from a user point of view.

The most interesting thing to most of you might be that JFace has now adopted the programming style from SWT and JFace-Coding feels now much more like SWT-Coding. Look at the next few lines and you understand what I mean:


Composite parent = ...;
TableViewer v = new TableViewer(parent);
v.getTable().setLinesVisible(true);

TableViewerColumn vColumn = new TableViewerColumn(v,SWT.NONE);
vColumn.getColumn().setWidth(200);
vColumn.setLabelProvider(new MyLabelProvider());

v.setContentProvider(new MyContentProvider());
v.setInput(model);

Are OS-ToolTips not flexible enough / Use JFace ToolTips

2006-11-15T09:08:00.000+01:00

How often have you wished that OS-Tooltips would provide more functionalities like MultiLine-Text, Background-Color, Embedded Images, ... . The time you faced those problems is over since today where JFace ToolTips are available to the public.

Usage is fairly straight forward:

Text text = new Text(parent,SWT.BORDER);
text.setText("Hello World");
DefaultToolTip toolTip = new DefaultToolTip(text);
toolTip.setText("Hello World");
toolTip.setBackgroundColor(parent.getDisplay().getSystemColor(SWT.COLOR_RED));

Easy isn't it but there are many many more things available to you. You can add any control you want to the tooltip by subclassing org.eclipse.jface.window.ToolTip and providing your own implementation for createToolTipContentArea.

public class MyToolTip extends ToolTip {
    private Shell parentShell;

    public MyToolTip(Control control) {
        super(control);
        this.parentShell = control.getShell();
    }

    protected Composite createToolTipContentArea(Event event, Composite parent) {
        Composite comp = new Composite(parent,SWT.NONE);
        comp.setLayout(new FillLayout());

        Button b = new Button(comp,SWT.PUSH);
        b.setText("Say Hello");
        b.addSelectionListener(new SelectionAdapter() {
            public void widgetSelected(SelectionEvent e) {
                hide();
                MessageBox box = new MessageBox(parentShell,SWT.ICON_INFORMATION);
                box.setMessage("Hello World!");
                box.setText("Hello World");
                box.open();
            }
        });
    }
}

Usage is the same than before:

Text text = new Text(parent,SWT.BORDER);
text.setText("Hello World");

MyToolTip myTooltipLabel = new MyToolTip(text);
myTooltipLabel.setShift(new Point(-5, -5));
myTooltipLabel.setHideOnMouseDown(false);
myTooltipLabel.activate();

The small difference is that you configure the tip to not hide when the user clicks into the ToolTip the ToolTip-Code needs to ensure the hiding by its own by calling hide().

There are other nice feature available to you:

possibility to define delay before the ToolTip pops up

possibility to define delay how long the ToolTip is shown

possibility to define the pop up position

possibility to define a shift like shown in the code above

possibility to completely control the popup position by overloading ToolTip#getLocation(Point,Event)

configure whether the bounds of the display and/or monitors should be:
- setRespectDisplayBounds(boolean)
- setRespectMonitorBounds(boolean)

at.bestsolution.jface32-0.0.1 released

2006-09-26T20:58:00.000+02:00

As promised I have released my JFace backport from 3.3 just a view days after 3.2 came out. You can get the ready plugin from my companies SVN-Repository.

JFace and features not part of Eclipse

2006-09-16T15:19:00.000+02:00

Today I sit down and thought it is time to provide features JFace won't provide (some of them are marked as later or are refused) in an own project named at.bestsolution.jface. Well 2 features I already had around somewhere in my workspaces:

TableViewer working with multiple instances of the same object
Dialog which could restore it's values because it's only hidden

All people interested in the work could as always fetch the sources from my companies SVN-Server. At the moment this plugin only depends on JFace but it's likely that this will change in future and org.eclipse.swt.nebula and at.bestsolution.jface32 will be added as dependencies. I haven't thoroughly tested because I never use it in my daily work so the QA is your part ;-)

How much can happen within one week?

2006-09-12T16:38:00.000+02:00

Back from holiday I see JFace's new viewer API evolving from week to week and getting more stable and userfriendly but some parts are not as smooth as they should be some work has to spent. The most markable things changed is that the caching of column-indices is gone completely.

Another important news is that Boris sorted out some VIRTUAL-Table bugs. As of this writing I have integrated all those changes to at.bestsolution.jface32 project. Simply fetch all changes from my companies (BestSolution Systemhaus GmbH) public SVN-Repository.

At the moment all things from JFace HEAD are integrated and because Tod, Boris and I all think that my widget-independency work can go in as is I've already integrated it. JFace integration will follow at the beginning 3.3M3 timeframe.

And last but not less important a new API-function has been added to set multiple filters at once this should avoid us to use all those nasty hacks to avoid flickering, ... .

I think I'll release a first version of the plugin with M2.

Finally to a new JFace project providing snippets to all show common JFace. The new project has been approved by the eclipse PMC and can be found in eclipse's CVS with contribution from Tod and myself

Viewer-Features form 3.3 in Eclipse-3.2

2006-08-27T20:41:00.000+02:00

There are many many exciting features added in 3.3 cycle to jface but many people need a solution now and not in 3.3-Timeframe. I myself have a need for some of those feature so I started back-porting them which is at the moment not really hard because at the moment JFace-Viewers doesn't use anything not available in 3.2-sources.

I decided to make them publicly available because I think many also have a need for them. So for those who want to use exciting features added in 3.3 can fetch the sources at in my companies SVN-Directory. Don't forget to do your own QA to ensure everything is working as expected. If you find bugs you can file them to my companies bug-tracking system at http://phpot.bestsolution.at/mantis/login_page.php and I'll try to incooperate them in eclipse bug-tracking system providing a patch for current HEAD-Trunk of CVS.

Before releasing a first version I'm trying to get the patches to 3.3-CVS-HEAD:

The current features/bug fixes against 3.2:

This project will only continue until 3.3 is out afterwards people will need to recompile their code replacing at.bestsolution.jface32.* through org.eclipse.jface.*.

At the end please note the following things:

this is nothing official from Eclipse and I only thought that there are maybe others who have the same needs than I have.
There's a great likelihood that new API added in 3.3 at some point will change while 3.3 evolves so the API you find now is maybe a subject to change in the next release.

Viewers-Refactoring

2006-08-24T14:27:00.000+02:00

Banging my head against Viewers since about a month we finally reached a state where it's possible the first time to use viewers with different widget than org.eclipse.swt.widgets.Table. At the moment only TableViewer supports widget independency but once this is in head. TreeViewer is the next to come.