Today I tried to start iReport for the first time on the Mac. There was a shell script distributed with the program, so I gave it a shot in the Terminal. Unfortunately I got an exception immediately.

Stryker:iReport-2.0.3 2 siker$ chmod a+x iReport.sh
Stryker:iReport-2.0.3 2 siker$ ./iReport.sh
Exception in thread "main" java.lang.NoClassDefFoundError: 2


I fooled around with the script for a while. Seeing that it was trying to generate its class path using creative uses of dirname on the first script argument, I figured that maybe it’d help to run the program with the full path specified like so:

Stryker:iReport-2.0.3 2 siker$ "`pwd`/iReport.sh"


That didn’t do it though. After looking at the script some more I realized they were pretty lax with quoting. That was it. Moving the software to a location without spaces in the path solved the problem and made iReport start up just fine.

Stryker:iReport-2.0.3 2 siker$ cd ..
Stryker:Downloads siker$ mv iReport-2.0.3\ 2 ~/iReport
Stryker:Downloads siker$ cd ~/iReport/
Stryker:iReport siker$ ./iReport.sh


Hope that helps someone running into the same problem. I would post a bug report but I saw someone was two steps ahead already and had created a clickable Mac application and submitted a build file. That’s clearly the preferable solution.

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.

Sorry for not posting anything here for quite some time. It doesn’t mean we don’t care about PWW anymore, it’s just that we haven’t found any way to extend the 24 hour limit of each day. If you have any suggestion on how to solve this, pleas let us know.

PS. We’ve tried ditching sleep, but that didn’t turn out to be a great idea in the long-run DS.

Just in case anyone runs into trouble with this, I just want to describe the steps for installing the symfony framework on an OS X 10.5 (Leopard) machine.

The good news is that Leopard comes with PHP 5 built in. The bad news is that PEAR is not included, which is needed to install symfony in the most convenient way.

My first attempt to remedy the situation was to run the darwin ports package manager to install pear:

# port install pear-base

Unfortunately there were two problems. First of all, the version of pear that comes with darwin ports does not use the OS X version of PHP by default, but rather looks for the PHP darwin port. This was easily remedied by adding export PHP_PEAR_PHP_BIN=`which php` to /etc/profile but unfortunately that’s not enough. The second problem is that a few files seems to be missing in the darwin port of PEAR and you’ll get the following error when you try to install symfony:


PEAR_Downloader::require_once(Structures/Graph.php): failed to open stream: No such file or directory in Downloader.php on line 1230



Indeed, even running pear install Structures_Graph results in this error message.

The Solution

This blog suggested go-pear.php as an alternative way to install PEAR on the Mac and it does work. So with no further ado, this is how to install symfony on Leopard:

sudo su -
curl http://pear.php.net/go-pear > go-pear.php
php -q go-pear.php

pear channel-discover pear.symfony-project.com
pear install symfony/symfony

Good luck with your Leopard powered symfony hacking.

If you’ve been reading our blog before, you’ve probably already figured out one thing: we love Open Source and Apple products. Because of this, all our desktop machines run either Linux or Mac OS. Although our mixture of platforms might not be representative for all organizations, this article is still likely to apply to all start-ups and companies that are trying to create a company-wide policy for document-formats.

In our organization today we have three different office suites:

• Open Office
• Apple iWork
• Microsoft Office

While all of these office suites have their pros and cons, they work just fine until the moment you try to move between suites. In the past in most organization it was often the case that everyone was forced to use Microsoft Office because some manager was bribed by Microsoft upper management said so. However, this is no longer a reasonable approach when we have a more diversified desktop environment than ever before. Today it’s no longer rare that we have Macs and PCs running both Windows, OS X and Linux in the same network. Because of this, forcing all users to use Microsoft Office is no longer reasonable.

First out: Microsoft’s .doc/.xls/.ppt

We’ve concluded that requiring all users to use the same software is unreasonable, but we still need to decide on one document-format that all users can both read and write. The first document format that comes to mind is the .doc-format for documents, and the .xls-format for spreadsheets. Let’s analyze this option a bit.

License: Microsoft’s own proprietary format.

Verdict: Ok, so all of the above editors support Microsoft’s proprietary file-formats. However, the drawback is that it is a proprietary format, which means that both iWork’s and Open Office’s implementation of these formats are most likely reverse-engineered. The real implication of this reverse-engineering is that the support is not really perfect. As you might have experienced, when using Open Office or Pages to export to .doc files, oftentimes the layout of the document is ruined. Since they layout tends to be quite important in business-documents, I would consider this a major drawback.

Next: Open Office’s .odt/.ods/.odp (Open Document Format)

You’ve probably already figured out that this would be our favorite, but let’s try to be unbiased. Similarly to the .doc/.xls/.ppt-combo, we’ll start out with a table of the support in the relevant applications.

Licensing: Creative Commons.

Verdict: Unfortunately it seems like the Open Document Format won’t work. Here the biggest problem is iWork. It is really a shame that Apple chose to not include support for this format. However, there might be an answer for why this is. According to Apple’s list of features in Leopard, we can see that there’s support for Open Document Format in TextEdit. Without having any evidence at all for this claim, we would guess that Apple intentionally chose to not include the support for Open Document Format in iWork simply because they would add support for the format on OS-level in Leopard.

The decision

As you can see in the charts above, none of the two alternatives is perfect. What holds the .doc/.xls/.ppt-combo back is its proprietary nature. Because of this, all the other applications fail to read and write these files good enough for a corporate environment. What holds the Open Document Format back is the lack of implementation in iWork. Moreover, it might also be cumbersome to have to use a plug-in to read and write Open Document Files in Microsoft Office, even that that’s still better than no support at all.

The bottom line is that at this point, the only possible approach is to use the .doc/.xls/.ppt-combo. Although we don’t like it, we’re out of luck with Open Document Format due to the lack of support in iWork. However, because of the uncertainty of the support of Open Document Format in Leopard, we will actually wait and see until it’s launched to take a formal policy decision on our Document-format.