[galileo] enter the twilight zone between target platform (runtime) and IDE (development)

Part 10 of my Galileo Reviews around Target Platforms. An Overview of this blog series can be found here.

I told you that you always have to separate clearly between

  • IDE (development, workbench)
  • Target Platform (Runtime, Product)

but there’s also a twilight zone 😉

If you run /  debug your application you create a launch configuration, choose the plug-ins and start and while you’re developing you’re using the IDE and compiling against the Target Platform Plug-ins.

But there are situations where you are simulating a running product while you’re still inside the IDE:

  • testing your product
  • using an UI – designer tool and preview

Testing OSGI applications is a special topic and we should discuss this later – its not part of my Galileo review blogs.

In this blog entry I’ll concentrate on UI design.

The User Interface (UI) in my OSGI Enterprise Applications uses

  • Riena UI and Navigation
  • redView (Riena EMF Dynamic Views)
  • SWTDesigner

riena egg redView (Riena EMF Dynamic Views for Business Applications)

I’ll blog in detail about Riena UI and redView in my upcoming blog series “UI and RCP“.

And part 11 of this blog series around target platform will talk about use of Riena and redView (TP-only Plug-ins used in IDE and Target Platform).


While redView is used for all generated Views,  I’m using SWTDesigner in these use cases:

  • complex and not generated Views
  • partly generated Views
  • Riena Views (separating UI- and Controller code)
  • Eclipse Preference Pages (if you need more then Field Editors)

Riena 1.1.0 is part of the Galileo train and SWTDesigner 7.1.0 fully supports Galileo, Cocoa 32-bit and 64-bit, and Riena Views (separating UI and Controller – using Riena Ridgets). SWTDesigner 7.1.0 also has factory support and so we’ll be able to integrate dynamic redView composites into a complex View designed by SWTDesigner. Another positive thing about SWTDesigner: using this product I’m feeling like using an open Source product 😉 nightly builds, update site, great forum, fast response directly from developers, fast fixing bugs or enhancing features like supporting Riena Views – this isn’tn usual for many commercial products. but hey – there are the ppl telling you “HowTo develope Plug-Ins” 😉

BTW: If you’re developing an Open Source Product, then there’s a special License of SWTDesigner available – ask Instantiations.

SWTDesigner Design Mode

The SWTDesigner does a good job trying to show the View as it would look like in Runtime mode. This happens switching from Source to Design Mode and also hitting the “Preview” Button in SWTDesigners Toolbar.

SWTDesigner tries to “run” the code of your View inside the IDE and this can cause some problems, as you can imagine. If you try to open a View with SWTDesigner and getting a Stacktrace then most cases its the reason that SWTDesigner tries to run unresolved Code.

Problem accessing Icons (Images)

My OSGI Applications use at Runtime Riena’s ImageStore to manage image resources. (org.eclipse.riena.ui.swt.utils.ImageStore)

To provide images its easy using Riena’s extension point:

<extension point="org.eclipse.riena.ui.swt.imagepath">

and to get an image from Riena’s ImageStore you only need the name of the Image without knowledge about the Plug-in providing it:

 private static final ImageStore iStore = ImageStore.getInstance();

Riena’s ImageStore is only available if some Riena Bundles are running, which isn’t the case while designing a View inside the IDE. This means we cannot use the ImageStore for SWTDesigner.

SWTDesigner itself has some convenient Classes to work with Images and manages also the resources (com.swtdesigner.ResourceManager).

To get an image from SWTDesigner’s ResourceManager you need to know the providing Plug-in and the path of the image:

				"icons/" + "abc.png")

The goal is to use SWTDesigner comfort to design Preference Pages and also to use Riena’s ImageStore if running the Product.

SWTDesigner Design Mode

Fortunately SWTDesigner provides some nice features to help us:

  • java.beans.Beans.isDesignTime() supported
  • Prevent code to be processed by SWTDesigner


SWTDesigner supports java.beans.Beans.isDesignTime():

package java.beans;
public class Beans {
 * Test if we are in design-mode.
 * @return  True if we are running in an application construction
 *		environment.
 * @see java.beans.DesignMode
public static boolean isDesignTime() {
return designTime;

If you’re in DesignMode (Open Java class using SWTDesigner’s “Window Builder Editor”) you can test this easyly:

if (Beans.isDesignTime()) {
				"icons/" + "abc.png"));
	} else {

Now your code works in both cases – in Runtime using Riena’s ImageStore and also in SWTDesigner Design – or Preview Mode. For me its worth the small overhead in coding.
Prevent code to be processed by SWTDesigner
There’s not only Beans.isDesign() – you can also “hide” some parts of your code. Hidden code will not be processed by SWTDesigner – this is really useful in some cases to avoid Exceptions.

// $hide>>$ code not to use by SWTDesigner
// $hide<<$ [/sourcecode] If you surround cody with $hide tags, then this code will be hidden and not be used by SWTDesigner – if its only one line, then you can simply add

// $hide$

at the end of the line.

Problems initializing FieldEditors (Preference Pages)

If working with Preference Pages there’s also sometimes the problem initializing Field Editors – here’s an example how this can be solved:

private void addLnFField(Composite container){
Composite composite = new Composite(container, SWT.NONE);
String [][] lnfChoices;
// are we running in SWTDesigner designTime mode ?
if (Beans.isDesignTime()) {
lnfChoices =
new String[][] {
{ “swtdesigner1”, “” },
{ “swtdesigner2”, “” },
{ “swtdesigner3”, “” }
// $hide>>$ code not to use by SWTDesigner
if (getLnfServices() == null || getLnfServices().size() == 0) {
lnfChoices = new String [1][2];
lnfChoices[0][0] = “no Look and Feel found – Riena Default used\nplease ask your system administrator”;
lnfChoices[0][1] = “RienaDefault”;
} else {
lnfChoices = new String [getLnfServices().size()][2];
int x = 0;
for (Iterator i = getLnfServices().iterator(); i.hasNext();) {
IRedviewLnfService lnf = (IRedviewLnfService) i.next();
lnfChoices[x][0] = lnf.getDescription();
lnfChoices[x][1] = lnf.getID();
// $hide<<$ RadioGroupFieldEditor radioGroupFieldEditor = new RadioGroupFieldEditor( PreferenceLnfManagerConstants.P_LNF_CHOICE, "Available LnF - Themes", 1, lnfChoices, composite , true); [/sourcecode] In Runtime the Look and Feel choices depend from available OSGI Services:

lnf preferences runtime

At Designtime some hardcoded entries were displayed:

lnf preferences designtime

There will be more cases like these two examples, but I think you got the idea how to solve some of them.

The next part of my blog series around target platforms will talk about “Target Platform only Plug-ins inside IDE – redView and Riena“.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: