For an upcoming project I need to be able to show Flash videos inside of an RCP application. Java has never been known for its multimedia functionality so I didn’t have very high hopes.

Fortunately, with Java Media Components things seem to be moving in the right direction. JMC is an API that allows you to play media files using the video functionality of the underlying operating system (there is work being done to provide cross-platform codecs along with the API, but it’s unclear how extensive this will be). JMC is distributed as part of the JavaFX platform, but it can function independently inside of a regular Swing application.

Using this recent article as a guide, I managed to create an Eclipse plug-in that contributes a very rudimentary video player view to Eclipse or any other RCP application. If you’d like to try it yourself, click here for the source code (exported project). Note that the current code only works on Windows.

Above you can see a Flash video of Wipeout playing inside of my Eclipse IDE. Wipeout is my 5-year old daughter’s favorite show (if people are falling down, she’s laughing), so after 20 years as a software developer I’ve finally written some code she’d be interested in!

One thing to note is that JMC relies on the codecs installed on your machine. There have been some complaints that JMC is not finding or utilizing the codecs most people have installed, and hopefully this situation will improve. If you find that you’re getting MediaUnsupportedException errors when opening files, you may want to install a codec pack. The CCCP pack seems to work for most people.

Share/Save

Last week Prakash G.R. wrote an excellent post on Using progress bars. This is definitely a post that I’ll be referring my students to in the future. There is still one missing piece to the progress bar puzzle, though, and that is how to add the Progress View itself to your application.

You might think that this view would appear on its own when requested through the UI, and in my opinion this is the way things should be (this has been discussed in past Bugzilla entries). For instance, your users may see a job running in the status bar of your RCP application, like this:

When the user clicks on the conveyor belt icon, they would expect to see a detailed progress view allowing them to cancel the job, like this:

So how do you get this working? The answer is not what you might think. Normally, you would add a view by finding the view class and creating a new view extension. But for the Progress View, things are a bit different. The ProgressView class itself is internal and is not intended to be referenced directly. It is exposed, however, through an extension factory. The XML to create the view extension looks like this:

   <extension
         point="org.eclipse.ui.views">
      <view
            name="Progress View"
            icon="icons/pview.gif"
            category="org.eclipse.ui"
            class="org.eclipse.ui.ExtensionFactory:progressView"
            id="org.eclipse.ui.views.ProgressView">
      </view>
   </extension>

The last piece we need to make this work is the view icon, which can be found in the org.eclipse.ui.ide plug-in (not part of the RCP SDK). The actual file in this plug-in is icons/full/eview16/pview.gif. You’ll need to copy this icon into your own plug-in and reference it in the view extension.

So while not extremely straightforward, it’s not that difficult either. Interestingly, there are a variety of other things you can add to your application through the same extension factory mechanism. If you’d like to find out more, check out the constants in the ExtensionFactory class.

Share/Save

One issue that developers new to RCP face is whether to add UI elements programmatically or declaratively. In my experience, most initially choose the programmatic approach because it seems more familiar. You know, why mess with extension points when you can just code it up and be done with it.

But it’s almost always better to do things declaratively through extension points, the main reason being that doing so allows you leverage the power of RCP as a modular user interface framework. To illustrate this, let’s look at our options for laying out perspectives.

Programmatic Layout = Centralized / Hard Coded

Here is the simplest code needed to add a view to a perspective programmatically. To do so, we implement the IPerspectiveFactory interface and add a view using its string id.

public class MyPerspectiveFactory implements IPerspectiveFactory {

	public void createInitialLayout(IPageLayout layout) {
		layout.addView(MyView.ID, IPageLayout.BOTTOM, 0.5f, layout.getEditorArea());
	}

}

The problem here is that we’ve coupled our perspective to the view being added. This view may exist in the same plug-in as the perspective, but often it does not. If the view is in a different plug-in, we have to declare a dependency on that plug-in just to add the view. It’s possible to reduce the coupling somewhat by replacing MyView.ID with the actual string id itself, but hidden dependencies based on string equivalency are arguably even more smelly.

In the end, a programmatic perspective layout results in a hard-coded and centralized architecture looking like this.

Declarative Layout = Decentralized / Modular

The declarative approach based on extension points resolves these issues. To layout a perspective declaratively we extend the org.eclipse.ui.perspectiveExtensions extension point.

   <extension
         point="org.eclipse.ui.perspectiveExtensions">
      <perspectiveExtension
            targetID="com.mycompany.myperspective">
         <view
               id="com.mycompany.myview"
               minimized="false"
               ratio="0.5"
               relationship="left"
               relative="org.eclipse.ui.editorss">
         </view>
      </perspectiveExtension>
   </extension>

Using this approach, each plug-in adds the views that it knows about, resulting in a decentralized architecture where the plug-ins containing the views are now in control.

Note that we have not eliminated all coupling, as the perspective extensions still need to refer to the perspective by its string id, but this is not as bad as it sounds. Perspectives are much more static than views – you typically define them and make few changes afterwards. Views, on the other hand are often moved from one plug-in to another or have their purpose (and potentially their id) redefined. Decentralizing control allows you to make these kinds of changes without breaking the perspective layout.

Conclusion

Adding UI elements declaratively is definitely the way to go. It gives you much more flexibility (e.g. you can add views to perspectives you didn’t create) and also allows you to leverage the modular nature of the framework.

Sure, there will always be cases where a declarative approach cannot be taken, particularly when some part of an API is not yet surfaced in the related extension point. But in the absence of such a need, I urge RCP developers to always turn first to the extension point mechanisms and fall back to programmatic approaches as a last resort. As your application evolves over time, you’ll really come to enjoy the flexibility and increased reusability that a declarative approach makes possible.

Share/Save

Setting up a target platform for an Eclipse Rich Client Platform application is fairly simple. You simply download the RCP SDK, extract it to a directory, and then use the Target platform preferences page to point to the new directory. But managing target platforms over time can be more complicated, and I’d like to pass along a few tips I’ve learned the hard way.

Maintain a separate target platform for each application.

The plug-ins that make up a target platform are as much a part of your application as the code you write, and this set of plug-ins will vary from one application to the next. One application might require the forms API. Another might use cheat sheets. Creating individual target platforms for each applications allows you to more easily manage these dependencies.

Make it easy for developers to create or link to target platforms.

Developers come and go on most projects and the first thing a new developer will need to do is set up a target platform. One way of making this easier is to create a wiki page listing the plug-ins that make up a target platform. Even better, just keep your target platform on a shared drive so everyone on the team can access it.

Version your target platforms.

Wiki pages and shared folders are great, but if you want to go all the way, consider versioning your target platforms along with your application source code. This makes it even easier to support new developers, and also makes it much easier to rebuild previous versions of your application.

Adding a new plug-in to your target platform is a big deal.

Adding a plug-in should be an explicit decision driven by your application’s requirements. When using the default target platform (Eclipse itself), it’s much too easy for developers to simply add dependencies on whatever plug-ins they like. Adding a new plug-in will generally require changes to your feature definitions, launch configurations, production configurations and automated build processes. Make sure the decision to add a plug-in to your application gets the deliberation it deserves.

A little work up front goes a long way.

Having said all that, I don’t want to make dealing with target platforms sound like rocket science. It’s usually a fairly simple aspect of RCP application development, as long as you treat it with the respect it deserves. The teams I see suffering from complications are those that never specifically address the issues posed by target platforms. With a little effort up front you can save yourself from some serious headaches.

Share/Save