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