I enjoy seeing people use EclipseRT technology in the wild. Recently I met and spoke with Austin Riddle from the Texas Center for Applied Technology (TCAT) about how they are using the Eclipse Rich Ajax Platform (RAP) and what applications they are building with it.

1. What does your application(s) do?

We have several live RAP applications that take the form of information dashboards. These dashboards allow decision-makers and analysts to disseminate information and produce a common operating picture related but not limited to global biosurveillance and large-scale emergency preparedness/management. Users can log in to our systems, customize their view of information via component and profile switching, visually integrate information within the dashboard and selectively share information between echelons of human infrastructure. Our US government customers have been very pleased with the power and flexibility of the systems.

2. Why did you choose Eclipse RAP?

We needed a powerful Rich Internet Application. We needed one that had to provide capabilities that frankly push the limits of what a traditional RIA could deliver. It also had to perform on older hardware and software. After working with and analyzing other options, including GWT, Flex, OpenLaszlo and others, we decided that RAP provided both the features we needed to fulfill our requirements, and the framework to develop custom features that empower our users even more. Being able to leverage other Eclipse Runtime Technology in our applications greatly reinforced our decision.

3. How did single sourcing benefit your project?

Our organization has a significant investment in Eclipse RCP capabilities that we needed to leverage in order to meet our dashboard requirements. It was amazing to see elements from our desktop systems just “appear” in our RAP application after just “dropping” the bundles in. Also, during our development process, we actually wrote capabilities in our RAP application that could be used in our desktop RCP applications. This “reverse” single sourcing was a pleasant surprise!

4. In the end, how did RAP help and benefit your project?

Most impressively, we were able to implement a first working prototype of a dashboard system in 30 days! RAP gave us the ability to rapidly prototype and ultimately provide solid systems that have withstood the scrutiny of rigorous government security evaluations. Currently, we are looking into bringing even more of our eclipse-based desktop investments to the web.

Cool stuff, huh?

Tags: case study, eclipseRT, rap, rcp

There has been a lot of talk lately about p2.  While many people know p2 as the update mechanism used by Eclipse, it is in fact a general purpose provisioning platform.  This means you can use the provisioning platform as a base to build a highly customized provisioning solution for your own needs… whether it is an Eclipse application, OSGi application or anything else.

On September 15, I will be presenting an introduction to p2. In particular, I will demonstrate how you can use p2 to build a provisioning solution for Eclipse RCP applications. The webinar will teach you how you can:

• Make use of the p2 provisioning platform for software management
• Integrate the creation of p2 repositories into your build system
• Reuse the p2 user interface and existing work-flows
• Customize the p2 user interface for your specific needs
• Debug common pitfalls

For more information, please see the registration page.

If you want anything else discussed about p2 in the webinar, please leave a comment and if there is time, I will try to get to it.

Tags: p2, rcp, webinar

When adding keybindings to an existing Eclipse RCP application, it is extremelly helpful to get realtime information about which keybinding registered and to what command handlers it is mapped to. Why is that?  Because sometimes the operating system or another widget will consume the keyboard event before it gets to the command framework. Other times there are several handlers bound to the same key causing a conflict.

Enabling Tracing for Keybindigs

Fortunatelly, this information is easy to get, if you enable the right tracing options:

org.eclipse.ui/debug = true
org.eclipse.ui/trace/keyBindings = true
org.eclipse.ui/trace/keyBindings.verbose = true

After that each keystroke will produce some output on the console:

KEYS --- WorkbenchKeyboard.press(potentialKeyStrokes = [CTRL+PAGE_UP, CTRL+])
KEYS --- WorkbenchKeyboard.executeCommand(commandId = 'org.eclipse.riena.navigation.ui.previousSubApplication', parameters = {})

In the above you can see that Ctrl+PageUp is mapped to the ‘previousSubApplication’ command.

Some times there is a conflict – i.e. one keybinding is mapped to two or more ‘active’ command handlers. This looks like this:

BINDINGS --- A conflict occurred for CTRL+SHIFT+W
BINDINGS ---     [Binding(CTRL+SHIFT+W,
	ParameterizedCommand(Command(org.eclipse.ui.file.closeAll,Close All,
		Close all editors,
		Category(org.eclipse.ui.category.file,File,null,true),
		org.eclipse.ui.internal.CloseAllHandler,
		,,true),null),
	org.eclipse.ui.defaultAcceleratorConfiguration,
	org.eclipse.ui.contexts.window,,,system), Binding(CTRL+SHIFT+W,
	ParameterizedCommand(Command(org.eclipse.riena.navigation.ui.closeModuleGroup,Close module group,
		,
		Category(org.eclipse.riena.navigation.ui.swt,Riena Navigation Commands,null,true),
		org.eclipse.riena.internal.navigation.ui.swt.handlers.CloseModuleGroup@39880a,
		,,true),null),
	org.eclipse.ui.defaultAcceleratorConfiguration,
	org.eclipse.ui.contexts.window,,,system)]

What happened here is that Ctrl+Shift+W was already bound to the CloseAllHandler via the ‘file.closeAll’ command. I was not aware of this initially, because it is defined in the org.eclipse.ui plugin. So I accidentally bound another command and handler to Ctrl+Shift+W. With the output I quickly realized what was going on. I ditched my own command and instead made ‘CloseModuleGroup’ a handler for the ‘file.closeAll’ command.

Tags: bindings, eclipse ui, jface, rcp, tips

This Thursday (July 9th), there will be a webinar on the topic of single sourcing and in particular, extending Rich Client Platform (RCP) applications to the web using the Rich Ajax Platform (RAP) project.

Don’t know what single sourcing is all about? Well, if we look at the traditional definition from the publishing industry:

Sounds like a good idea?

How about we take that a step further and talk about source code and runtime environments:

In our definition of single sourcing, you’re able to take desktop applications built with RCP and run them on the web using RAP. During the webinar, Ralf Sternberg and Ruediger Herrmann will explore the differences between RAP and RCP that are especially relevant to the goal of single sourcing as much code as possible. This means that you’re able to reuse a lot of code and skills in single sourcing projects. If you’re still a bit fuzzy on the topic, a concrete example of single sourcing in practice was the Eclipse Memory Analyzer (MAT) project:

So what are you waiting for, please register for the webinar!

Tags: eclipse, rap, rcp, Single Sourcing, webinar

Enabling RCP applications to work with different locales is an essential requirement for server-side Eclipse setups. Multiple users are accessing the same instance of a running application concurrently, and each one should see the UI in his preferred language. Providing a server-side platform, the RAP project faced this problem too and we needed to find solutions to support multiple locales.

Recently I had the chance to discuss with Jeff McAffer how these changes could be integrated into Equinox. There are a number of subtasks to solve:

1. The NLS class must support different locales. Currently, translated strings are kept in static fields.
2. The extension registry must support reading in different locales. Currently, translatable strings in extensions are resolved once at startup and the results are cached.
3. There must be a mechanism to obtain the default locale for the current user and/or API to request a string in a certain locale.

I opened a new bug for the overall multi-locale topic and added patches to these bugs. Currently, comments show that there is no consensus on the suggested solution yet. These patches solve the requirements related to RAP, however, other projects may have different needs. If you have use cases related to multi-locale, please share your comments on the bug.

At any rate, multi-locale support is needed and it would be great to have it even in Eclipse 3.6.

So please comment on the bugs and help to push on this topic!

Tags: nls, OSGi, rap, rcp

In SWT, the mantra is “if you created it, you dispose it.”

The problem is, people forget to dispose which makes leaks a reality.

For example, ever come across this dreaded exception from SWT?

...
org.eclipse.swt.SWTError: No more handles
at org.eclipse.swt.SWT.error(SWT.java:2966)
at org.eclipse.swt.SWT.error(SWT.java:2863)
at org.eclipse.swt.SWT.error(SWT.java:2834)
at org.eclipse.swt.widgets.Widget.error(Widget.java:395)
at org.eclipse.swt.widgets.Control.createHandle(Control.java:482)
at org.eclipse.swt.widgets.Composite.createHandle(Composite.java:229)
at org.eclipse.swt.widgets.Control.createWidget(Control.java:497)
at org.eclipse.swt.widgets.Scrollable.createWidget(Scrollable.java:131)
at org.eclipse.swt.widgets.Control. (Control.java:97)
at org.eclipse.swt.widgets.Scrollable. (Scrollable.java:72)
at org.eclipse.swt.widgets.Composite. (Composite.java:87)
...

One of the most common causes of this type of exception is a resource leak. In SWT, you’re allocating operating system resources for widgets, images, fonts, and other graphical objects. Since there is a platform-specific limit on the amount of resources you can allocate, you must be careful to free any objects that you allocate. To see what resources your application has allocated, the SWT team has a tool called Sleak. To get an idea of how Sleak works, let’s modify the famous RCP Mail example. The first step will be to add the Sleak view to the RCP Mail perspective (Perspective.java):

layout.addStandaloneView(NavigationView.ID,  false, IPageLayout.LEFT, 0.25f, editorArea);
IFolderLayout folder = layout.createFolder("messages", IPageLayout.TOP, 0.5f, editorArea);
folder.addPlaceholder(View.ID + ":*");
folder.addView(View.ID);
folder.addView("org.eclipse.swt.sleak.views.SleakView"); // add sleak here!

The next step is to simulate a leak so we can show the benefit of using Sleak. We can simulate a resource leak by creating a bold font and never disposing of it in the RCP Mail view (View.java):

...
// setup bold font
// comment out the safe way of getting a bold font via the jface registry
// Font boldFont = JFaceResources.getFontRegistry().getBold(JFaceResources.DEFAULT_FONT);
FontData[] fontData = JFaceResources.getDialogFont().getFontData();
for (int i = 0; i < fontData.length; i++) {
	FontData data = fontData[i];
	data.setStyle(SWT.BOLD);
}
boldFont = new Font(parent.getDisplay(), fontData); // this should be disposed in dispose()
...

Ok, now that we have the code modifications out of the way, we need to launch our application. Note, in order to have Sleak function properly, you have to enable some options:

org.eclipse.ui/debug=true
org.eclipse.ui/trace/graphics=true


The easiest way to do this is in your Eclipse application launch configuration. There is a ‘Tracing’ tab that allows you to tweak options:

Once that is done, we can launch our application and find the ‘Sleak’ view:

If you press the ‘Snap’ button in Sleak, it will take a snapshot of the current allocated resources. To demonstrate the leak, we need to open two more messages in the mail application, close both of them, and then go back to the Sleak view to press the ‘Diff’ button:

Sleak now informs us that there are two more fonts allocated than before, we have found our leak! If you click the ‘Stack’ option, you can even get a stracktrace that tells you where the resource was allocated. A fix for this problem goes back to the SWT mantra of “if you created it, you dispose it.” In our view, we simply need to dispose of the bold font when we’re done using it (or use the font registry like before):

...
public void dispose() {
     super.dispose();
     boldFont.dispose(); // we need to dispose that font to prevent a leak!
}
...

Here’s a zip of mail example with the leak if you want to toy with Sleak.

Hope this helps!

Tags: rcp, swt

As a Riena committer, it’s always nice to see people taking interest in Riena. Feedback  at EclipseCon has been very positive. I was also impressed by  RedView – a UI-generator based on EMF and Riena, which is becoming available soon.

Now James Sugrue wrote “Riena – A New Adventure in Eclipse” over on DZone.

The article introduces Riena, walks you through installation, shows how to create and theme an application and explains Riena’s remote services. Go check it out.

Kind regards,
Elias.

Tags: eclipse ui, rcp, riena

For simple RCP Applications the Perspective-Switcher widget that ships with Eclipse is overloaded and cumbersome to use.

We are going to get rid of it and replace it with an equivalent menu and/or toolbar for switching perspectives. Both should have an indicator to show which perspective is currently active.

Hiding the Perspective-Switcher

To hide the Perspective-Switcher we go to our ApplicationWorkbenchWindowAdvisor and instruct the IWorkbenchWindowConfigurer to not show the perspective bar.

public void preWindowOpen() {
  IWorkbenchWindowConfigurer configurer = getWindowConfigurer();
   configurer.setShowPerspectiveBar(false);
  // ...
}

Using simple commands – not enough

Let’s see how we could contribute a menu / toolbar for switching perspectives. 

The workbench has the command ‘org.eclipse.ui.perspectives.showPerspective’ that can switch to a given perspective. It accepts a parameter ‘org.eclipse.ui.perspectives.showPerspective.perspectiveId’ with the ID of the perspective to show. Optionally a second parameter ‘org.eclipse.ui.perspectives.showPerspective.newWindow’ will open the perspective in a new window if set to ‘true’.

Using  the ‘org.eclipse.ui.menus’ extension point we could contribute a menu with an appropriate <command> for each perspective:

   <extension
         point="org.eclipse.ui.menus">
      <menuContribution
            locationURI="menu:org.eclipse.ui.main.menu">
         <menu
               id="menu.perspectivesStatic"
               label="Perspectives">
            <command
                  commandId="org.eclipse.ui.perspectives.showPerspective"
                  icon="/icons/perspA.png"
                  label="Perspective A"
                  style="radio">
               <parameter
                     name="org.eclipse.ui.perspectives.showPerspective.perspectiveId"
                     value="example.perspectiveswitch.simple.PerspectiveA">
               </parameter>
            </command>
            <!-- repeat --!> 

Unfortunately this approach has some drawbacks:

• long xml files
• the list of available perspectives is static – brittle and requires manual maintenance
• it is difficult to indicate which perspective is currently selected

Using dynamic contributions – success

Fortunately the <dynamic> element of  ’org.eclipse.ui.menus’ comes to our rescue. It allows us to contribute a Java class that populates the menu/toolbar on the fly (note: use a separate class for each).

Here’s the <dynamic> element that populates the ‘Perspectives’ menu:

   <extension
         point="org.eclipse.ui.menus">
      <menuContribution
            locationURI="menu:org.eclipse.ui.main.menu">
         <menu
               id="menu.perspectivesDynamic"
               label="Perspectives">
            <dynamic
                  class="example.perspectiveswitch.PerspectiveSwitcherMenu"
                  id="perspectiveSwitcherMenu">
            </dynamic>
      </menuContribution>
   </extension> 

The class PerspectiveSwitcherMenu fills the menu on the fly.

We obtain the array of  IPerspectiveDescriptors from the workbench. For each we create a MenuItem with the perspective’s icon and description. Since we created images, we have to dispose them when the menu item is disposed, using a dispose listener. A selection listener is in charge of switching perspective when a menu item is clicked. To provide indication about the active perspective we use the SWT.RADIO style and select one of the menu items. Since the menu is created on the fly each time it is used, we do not need to track the active perspective .

public class PerspectiveSwitcherMenu extends ContributionItem {

public void fill(Menu menu, int index) {
  String activePerspective = getPerspectiveId();
  IPerspectiveDescriptor[] perspectives = PlatformUI.getWorkbench().getPerspectiveRegistry().getPerspectives();
  for(int i = 0; i < perspectives.length; i++) {
    IPerspectiveDescriptor descriptor = perspectives[i];
    // i is used as an item index; 0-n will add items to the top of the menu
    MenuItem item = new MenuItem(menu, SWT.RADIO, i);
    item.setData(KEY_PERSPECTIVE_DESCR, descriptor);
    item.setText(descriptor.getLabel());
    final Image image = descriptor.getImageDescriptor().createImage();
    item.setImage(image);
    item.addDisposeListener(new DisposeListener(){
      public void widgetDisposed(DisposeEvent e) {
        image.dispose();
      }
    });
    item.addSelectionListener(menuListener);
    if(descriptor.getId().equals(activePerspective)) {
      item.setSelection(true);
    }
  }
}

public final boolean isDynamic() {
  return true;
}

The toolbar contribution is very similar to the above. Using the ‘org.eclipse.ui.menus’ extension point, we add a <dynamic> element to a <toolbar>. We then implement PerspectiveSwitcherToolbar which extends ContributionItem and overrides the fill(Toolbar, int) to create a toolbar on the fly.

Since the toolbar is visible all the time, we have to track the active perspective, so we can update the ‘selected’ (=depressed) state of the toolbar buttons as necessary. This turned out to be quite tricky. Here’s the solution I went for: a listener tracking the active perspective is installed in each window. If the perspective changes, we look-up the toolbar and update the ‘selected’ state. Since windows may come and go, a second listener keeps track of window creation / disposal and installs / removes the perspective listener as necessary. I wish this was a bit easier – but I’m sharing the below code so you can save a bit of time on this.

Source Download

Download the full code here: example perspective switch.zip

Happy hacking,
Elias.  

PS: If you want to trade off more screen real-estate for a fancier switcher you can use a ‘standalone’ view or a composite that is placed around the page contents. Tom Seidel has the details on his blog.

Tags: eclipse ui, rcp, tips

Boris Bokowski and I are in charge of the UI and RCP track at EclipseCon 2009. It took forever to weed through all the submissions, but we eventually made some choices and I think we put together an excellent program. We have three tutorials:

Building Commercial-Quality Eclipse Plugins
RCP Mail 2.0: Commands, Common Navigator, and Data Binding
Advanced Eclipse Rich Client Platform

These tutorials should provide great coverage for beginners and even experts. For beginners, I’d highly recommend Dan Rubel and Eric Clayberg’s tutorial on building commercial quality plug-ins. These are the same guys behind the book that shares the same name as the tutorial. For experts, the other two tutorials are good options, however, I’m personally excited about the RCP Mail 2.0 tutorial as I want the outcome of that tutorial to result in a new PDE template that can be used by all. At least, that’s my hidden agenda in vouching for that tutorial

For long talks, we have plenty but here are three of my favorites:

Eclipse on Rails and Rockets
Sleeping Around: Writing tools that work in Eclipse, Visual Studio, Ruby, and the Web
Max and John’s Excellent Plug-in Adventure: The Highlight Reel

The main stage talk should be really interesting as you get to hear from two adopters of Eclipse… and how they used Eclipse technology within NASA and the Swiss Railway system. Then you have a talk by some old Eclipse committers that decided to stress themselves out by writing tools that run anywhere… from Eclipse to Visual Studio. Finally, there will be an entertaining talk from Max and John about Eclipse plug-in development anti-patterns.

We also have a lot of short talks but here are three I’m personally looking forward too:

Carbon Dating: The treacherous path from Carbon to Cocoa for SWT
Nuclear Eclipse : Eclipse in nuclear power plants
Real World RCP

It’s always entertaining to hear Steve Northover talk, he’s like a wise guitar-playing sage. Joining Steve will be Scott Kovatch from Adobe, they will talk about the challenges in getting the SWT Cocoa port ready for Galileo. I’m impressed with the work so far as I’ve been using the SWT Cocoa port since Eclipse 3.5M4 and it’s been pretty stable. It will definitely be ready for the prime time when Galileo ships. The other two short talks I like are more case study related… and always fun to listen to. I mean, Eclipse in nuclear power plants… that’s awesome!

So there you have it. All I can say is that I hope you enjoy the program this year! See you in March!

Tags: eclipse, eclipsecon, nasa, rcp

Have you ever come across an issue while developing an Eclipse-based application, go to export it and get an evil “Invalid character constant” message or something similar in your logs? This happens when you’re developing an application that requires Unicode characters but your system file encoding is something other than you expect (i.e., on Macs it’s usually MacRoman and on Windows it’s Cp1252). When you go to export, PDE Build will use the default file encoding (see the file.encoding system property) available to the VM. This can cause problems if you’re using Unicode characters in code and on export, PDE Build chooses a default encoding like Cp1252.

In Eclipse 3.5M5, PDE added some checks to make sure that your project encoding matches what would be exported:

This is accomplished via the javacDefaultEncoding.<library> property (in your build.properties file). This doesn’t help you much if you need to do file-specific encodings, but PDE Build supports that via the javacCustomEncodings property. For example:

javacCustomEncodings.. = src/org/foo[US-ASCII],\
src/org/foo/bar.java[ISO-8859-1]


Hope this helps!

Tags: eclipse, encoding, pde, rcp, tips