Monday, October 27, 2008

News about UFacekit

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

Friday, October 24, 2008

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

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);

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);

EditText text = new EditText(this);

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() + "!");;


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?

Sunday, October 19, 2008

Update on UFacekit

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
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.

Wednesday, October 08, 2008

Disable parts SWT-Table/Tree with SWT.CHECK

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);

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 {
TreeItem item = (TreeItem)tree.item;
item.setChecked(! item.getChecked() );
} finally {

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.