Tom over at the eclipse-dev blog posted this useful snippet for putting native looking checkboxes in SWT JFace TableViewer tables. Unfortunately the checkboxes ended up with a gray background in OS X, as seen in the picture below.

An unsightly gray checkbox background.

I came up with this hack to hack the hack to work.

private Image makeShot(Control control, boolean type)
{
	// Hopefully no platform uses exactly this color
	// because we'll make it transparent in the image.
	Color greenScreen = new Color(control.getDisplay(), 
		222, 223, 224);

	Shell shell = new Shell(control.getShell(), 
		SWT.NO_TRIM);

	// otherwise we have a default gray color
	shell.setBackground(greenScreen);

	Button button = new Button(shell, SWT.CHECK);
	button.setBackground(greenScreen);
	button.setSelection(type);

	// otherwise an image is located in a corner
	button.setLocation(1, 1);
	Point bsize = button.computeSize(SWT.DEFAULT, 
		SWT.DEFAULT);

	// otherwise an image is stretched by width
	bsize.x = Math.max(bsize.x - 1, bsize.y - 1);
	bsize.y = Math.max(bsize.x - 1, bsize.y - 1);
	button.setSize(bsize);
	shell.setSize(bsize);

	shell.open();
	GC gc = new GC(shell);
	Image image = new Image(control.getDisplay(), 
		bsize.x, bsize.y);
	gc.copyArea(image, 0, 0);
	gc.dispose();
	shell.close();

	ImageData imageData = image.getImageData();
	imageData.transparentPixel = imageData
		.palette.getPixel(greenScreen.getRGB());

	return new Image(control.getDisplay(), imageData);
}

The result now looks like the picture below.

It’s not pixel perfect but closer.

It’s based on Florian Potschka’s version of makeShot as found in the comments to the original post. Replacing your makeShot method with the one above makes the background of the checkbox transparent. It’s not perfect: we use a random near white background color as our ‘green screen’ color in order to get the right antialias color in the edges. But this will also make any pixels with exactly this color inside of the widget shine through. Hopefully there won’t be many. Given enough time somebody will add checkbox support to arbitrary table cells in SWT and this hack will be made obsolete.

Here’s the complete snippet (untested):

package de.fhmracing.glasseye.canexplorer.gui.transmit;

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.Color;
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.Control;
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(), false));
      JFaceResources.getImageRegistry().put(CHECKED_KEY,
          makeShot(viewer.getControl(), true));
    }
  }

  private Image makeShot(Control control, boolean type)
  {
    // Hopefully no platform uses exactly this color because we'll make
    // it transparent in the image.
    Color greenScreen = new Color(control.getDisplay(), 222, 223, 224);

    Shell shell = new Shell(control.getShell(), SWT.NO_TRIM);

    // otherwise we have a default gray color
    shell.setBackground(greenScreen);

    Button button = new Button(shell, SWT.CHECK);
    button.setBackground(greenScreen);
    button.setSelection(type);

    // otherwise an image is located in a corner
    button.setLocation(1, 1);
    Point bsize = button.computeSize(SWT.DEFAULT, SWT.DEFAULT);

    // otherwise an image is stretched by width
    bsize.x = Math.max(bsize.x - 1, bsize.y - 1);
    bsize.y = Math.max(bsize.x - 1, bsize.y - 1);
    button.setSize(bsize);
    shell.setSize(bsize);

    shell.open();
    GC gc = new GC(shell);
    Image image = new Image(control.getDisplay(), bsize.x, bsize.y);
    gc.copyArea(image, 0, 0);
    gc.dispose();
    shell.close();

    ImageData imageData = image.getImageData();
    imageData.transparentPixel = imageData.palette.getPixel(greenScreen
        .getRGB());

    return new Image(control.getDisplay(), imageData);
  }

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

  protected abstract boolean isChecked(Object element);
}

Hope it’ll help somebody.

SwtCallback 0.1 was released only a little more than a week ago, but that’s not stopping us from releasing 0.2 today! In line with the original philosophy, SwtCallback has been extended to again reduce clutter and deep nesting in your Java code. This time SwtCallback attacks the Runnable interface.

As I wrote in my release post about SwtCallback, SwtCallback is a java library for SWT applications which adds an alternative way to handle events: callbacks. Instead of clunky listener interfaces or messy anonymous classes, SwtCallback enables one line solutions that make it easy to keep your event handling code in a single flat class – this while still being more readable and (surprisingly) improving encapsulation in some cases.

This latest release extends this functionality from just listeners to anything that takes a runnable. Prime examples in SWT are display.syncExec(), display.asyncExec() and timers.

For example, maybe you wish to refresh some UI components to reflect a change in data. But you’re not on the SWT thread so you have to use syncExec. Normally, you’d do something like,

display.syncExec(new Runnable() {
  public void run() {
    doUpdateSwtLabels();
  }
});

With a Callback you can turn this into one highly readable line:

display.syncExec(new Callback(this, "doUpdateSwtLabels"));

The most useful application may be for timers. In SWT, a timer needs to be reestablished at the end of timer execution if you wish it to recur. You may end up with unwieldy code such as,

void initWidgets() {
  /* ... */

  // Prime the timer.
  display.timerExec(INITIAL_DELAY, new Runnable() {
    public void run() {
      refresh();
    }
  }); 
}

void refresh() {
  /* ... update stuff ... */
  
  // Set the timer again.
  display.timerExec(TIMER_DELAY, new Runnable() {
    public void run() {
      refresh();
    }
  }); 
}

With a Callback you can now do this:

void initWidgets() {
  /* ... */

  // Prime the timer.
  display.timerExec(INITIAL_DELAY, 
    new Callback(this, "refresh")); 
}

void refresh() {
  /* ... update stuff ... */
  
  // Set the timer again.
  display.timerExec(TIMER_DELAY, 
    new Callback(this, "refresh")); 
}

This is much easier to read and follow, at least in my personal opinion. If you agree, go ahead and grab the download below – SwtCallback is released under the BSD license so you should be able to integrate it with whatever you’re working on.

Download the source and binary here:

Download SwtCallBack. More information is available here.

There’s some extra javadoc in this release to make it easier to get started. Still, there isn’t much in the way of documentation – we’ll go back and write some if there’s demand for it.

           

Today WireLoad is releasing SwtCallback, a Java library for SWT that enables callbacks for event handling. SwtCallback is inspired by the Swing enhancer Buoy by Peter Eastman.

If you know you want this, just skip to the bottom of this post for the download link. Otherwise, read on and I’ll explain the reason we wrote this library.

I’m a big fan of readable and concise code. Another thing I’m a big fan of is user interfaces that look and feel like what users expect. Given this, I’ve always had an aversion to UI programming in Java. Because I think it’s very telling, I’ll let this flash video illustrate: totally gridbag. Bottom line is that in Java, user interfaces look weird and often attempts to alleviate this weirdness result in enormous amounts of hard to read code.

One solution is to use the Standard Widget Toolkit (SWT) instead. SWT enables easier UI building with resulting UIs that are both faster and look and feel better for the end user. What’s more, the code is more concise thanks to FormLayouts, sane widget sizing and the availability of standard functionality.

There’s one thing I think can be improved on though: readability. SWT code has a tendency to, like Swing, become littered with hundreds of listener classes, or worse, faceless listener implementations. For example, your code may look like this:

public class Demo implements SelectionListener {

...
   void initialize() { 
      Button myButton = new Button(shell, SWT.NONE);
      myButton.setText("Click Me"); 
      myButton.addSelectionListener(this);
   }
...

   public void widgetDefaultSelected(SelectionEvent e) {
      // I don't care about this event but I have to 
      // have a handler to satisfy the interface.
   }

   public void widgetSelected(SelectionEvent e) {
      // Do something
   }
}

Notice how the method named ‘widgetSelected’ has a very generic name: it has to since that’s the name it was given in the SelectionListener interface. Also, if there are many widgets that listen for selection events, then this single method has to handle all of them with a big if statement or some such. Not very readable. We also had to thumb on conciseness by adding one method which we didn’t even want: widgetDefaultSelected.

A better method is to associate the handler with only a single widget by using an inner class, and to use an adapter to avoid having to add a dummy method. This would typically look like this:

Button myButton = new Button(shell, SWT.NONE);
myButton.setText("Click Me"); 
myButton.addSelectionListener(new SelectionAdapter() {
   public void widgetSelected(SelectionEvent e) {
      // Do something
   }			
});

Much better. Less code, easier to read and it’s clear what ‘do something’ is associated with. But now we end up with a bunch of anonymous classes and deeply nested code. It’s still not perfect.

Enter SwtCallback. With SwtCallback, our final version of the program may look like so:

void initialize() { 
   Button myButton = new Button(shell, SWT.NONE);
   myButton.setText("Click Me"); 
   Callback.add(myButton, SWT.Selection, this, 
      "myButtonSelected");
}

/**
 * Called when myButton is selected.
 */
@SuppressWarnings("unused")
private void myButtonSelected() {
   // Do something
}

This has everything we wanted: it’s clear what the ‘myButtonSelected’ method does because it’s well named. There are no listeners to implement and no inner class bloat. The definition of myButton is short without being complicated or hard to understand. As an added bonus SwtCallback allowed us to make the event handler method private – this makes sense since the method is only relevant for the corresponding UI class.

UI programmers with experience outside of Swing will hopefully immediately recognize and appreciate the idea of callbacks. If you still need more reasons though, I’ll suggest a couple:

• Less code means fewer bugs and easier maintenance. Callbacks allow you to handle events without lots of extra classes or big if-else statements.
• You can link many events to the same handler. For example, maybe you have a ‘Quit’ button in a window. This button can have the same handler as the standard close event for the window.
• No need for dummy methods. Since you’re not implementing listener interfaces you don’t have to implement handlers for events you don’t care about.
• Natural names for methods. You’re not constrained to some standard name for an event handler. You can name your method ‘handlePasswordFieldGainedFocus’ if you want to.
• Private or protected event handlers. With interfaces your event handling methods have to be public. Most of the time they’re very specific to some UI classes. It doesn’t make sense for other unrelated classes to call your handlePasswordFieldGainedFocus() method.

If you still need more, Peter Eastman, the author of Buoy, expresses the rationale for callbacks much better than I ever could here.

SwtCallback is released under the BSD license. Download the source and binary here:

Download SwtCallBack. More information is available here.

Patches and comments are welcome. Apologies for the lack of documentation – if there’s interest in this library we’ll revisit it. For now, if you find it useful, great!

Update 1: SwtCallback 0.2 has been released.