Skip to content

Archive

Tag: rcp

The Eclipse RCP became a prominent platform for building client software. One of the delivery mechanisms supported by Eclipse RCP is Sun’s Java Web Start (JWS). Since Galileo Edition some changes has been introduced in the platform. This article provides some hints for creation of the RCP delivered by Java Web Start.

Packaging

In order to package the RCP I suggest to use feature-based products as described in a previous article. Following it, you should have a top-level plug-in (also refered as product-defining plug-in) and top-level feature, which is called “wrap”-feature in the context of the Java Web Start.

Exporting the product

Before you start with Java Web Start (JWS), export the product and make sure it starts as a standalone application. In doing so, you have to ensure that your references to the plug-ins are correct. One of the way of doing it is to hit the Validate button in the top left of the product editor. If the validation is successful, try to export the product. The PDE builder will run and create a distribution. The errors of the compiler/builder/assembler, if any, are reported to files zipped to the logs.zip file in the distribution directory.

Abstract

compass After providing the basic example of how the Eclipse Common Navigator Framework (CNF) can be used to display custom content, this article focuses on the main feature of the CNF – the contribution of content to the same navigator by several independent plug-ins. First of all, I will explain some minor changes introduced to the CNF in the Gallileo Edition, then I will focus on the content itself and finally provide an overview of how the action contributions can be provided. In the end of the post, some ideas on control of dynamic content are explained.

Gallileo Changes

There are two noticeable changes in the CNF that have been added with Eclipse Galileo. The return type of the method continue reading…

Abstract

Passing Data between Plug-ins
The Eclipse Platform provides a very rich API for the development and configuration of plug-ins and RCPs. It does this in two ways: by providing the corresponding classes and interfaces or by using the extension point mechanism. During the development the question arises, how to develop own extension points and how those plug-in interfaces look like. This article summarizes some of my experiences with developing plug-ins extension points.

Introduction

The extensive use of extension points is the standard approach during the development of own plug-ins and Eclipse-based applications. Especially, in the 3.x branch, the Eclipse Developers introduced tons of new extension points, primarily for the user interface, moving towards the declarative definition of the UI. Even if the the topic of the definition of extension points is covered in several books and articles, it is a bit challenging to come up with a clean extension point design for a particular scenarios, especially for beginners. This has to do with the specific way, how the Eclipse platform handles extensions.

In order to have a concrete scenario, lets assume that a small RCP application consisting of two plug-ins is being developed. The application prints out the time every ten seconds. One plug-in is responsible for the functionality of the time generation (lets call it the Core plug-in) and another, for the presentation of the results of the first one (lets call it UI plug-in). The separation of code in UI and non-UI plug-ins is a common practice and the standard question is, how to to pass data between the two. In general we assume, that the UI plug-in depends on the Core plug-in.
continue reading…

Packaging

Abstract

Using Eclipse-based rich-clients as stand-alone applications is discussed in many books and articles. In the context of enterprise systems, the software development adopted several paradigms to improve the quality of the overall architecture. This short article describes some issues in packaging the application for using it in the context of enterprise systems.

Architectural Assumptions

Designing enterprise architectures is a standard discipline for IT-consulting companies or freelancers involved in software development. Maybe one of the main characteristics of enterprise architectures is the framework-driven approach of software creation. Thus, the software has to comply certain rules and standards adopted inside the enterprise. In order to simplify such constrained development process, it is common to use an in-house software framework, which enforces the  compliance of the enterprise-internal standards and acts as glue between different technologies adopted as parts of the enterprise architecture.

Using such frameworks has major implications for the software development in general, and especially for the rich client development. The design issues are summarized in the next section.

Usaging an Enterprise Framework

The major goal of the enterprise in-house framework is to simplify the process of software systems development and to enforce standardization among the software systems. This usually includes the following aspects:

  • Domain-specific component framework
  • Methods for master data management
  • Infrastructure services: authentication, authorization, communication, security, printing, reporting
  • Application skeletons and launchers

The more unification and standardization is included inside the framework, the easier it is for a software developer to concentrate on the particular business task and the easier is the maintenance of the software system.

From the previous list, the most interesting part related to RCP packaging and deployment is the existence of the application skeletons and launchers. So, when launching an application, the framework libraries are loaded and executed first and pass the control to the application-specific modules. The advantage of this approach is that infrastructure services can be loaded first, which can be developed and shared among different applications.
continue reading…

compas

Abstract

This article describes some efforts to use the Common Navigator Framework (CNF). In doing so it incorporates the information already covered in different articles, but also focuses on the specific use case of providing a view of something completely unrelated to the platform resources. So the aim is not to add some content to the “Project Explorer” which is an example of resource-oriented CNF usage, but to provide a view on a completely own data model.

Introduction

Project Explorer
A very common UI element to represent data is a tree view. In SWT this UI element is implemented using the Tree widget. Following the MVC design pattern in the TreeViewer, JFace simplifies the usage of the Tree widget by delegating the task of content adoption to the ContentProvider and the label production to the LabelProvider (and using Sorters and Filters for sorting and filtering). Still for a single representation one has to construct a viewer and configure it with a corresponding Label- and ContentProvider. Further code reduction can be achieved by the use of WorkbenchContentProvider and WorkbenchLabelProvider if the elements can be made adaptable (implement IAdaptable interface and making them first-class workbench citizens). This approach is helpful, if the elements has to be displayed in several different viewers (e.G. Table). Finally, the Common Navigator Framework (CNF) is a facility provided by the Eclipse Platform which allows the usage of multiple Label- and ContentProvider on the same view. The providers are activated and used dynamically and can be configured declarative or programmatically. The advantage of CNF approach is the ability to combine elements in one view which have different origins(e.G. contributed by different plugins). CNF is used in Eclipse IDE: e.G. “ProjectExplorer” and “CVS Synchrnoize” are both instances of the CNF.

The usage of the CNF in your own application for purposes of representation of resource-based (and usually file-based) content is discussed in articles of Micael Elder in detail. The main idea is to instantiate the view, declare the default content and UI interface and make some additions where needed. This post has a different aim: we start from scratch and represent completely resource unrelated content. Before diving in the implementation details, some overview is provided.

UI Overview

Project Explorer with default options There are many things which can be configured by the usage of CNF and it is beyond the scope of this post to cover all of them. Still there are several things to understand before the actual code can be written. The user interacts with a View which shows the data elements. Which elements are shown is configured using the navigation content extensions. Shown elements can be filtered with Filters and sorted using Sorters on behalf of the user. There are some predefined actions and their positions in the UI and corresponding extension points to contribute to. Project Explorer Pop-up. The actions for Working sets, Customize View, Link with editor belong to this category. The user can also right-click on particular element in the tree and sees a popup-menu. This menu is configured based on the content element and can be (is) contributed by several plugins. The action contribution is also covered in the article series from Michael Elder.

continue reading…

helpEclipse Platform provides a help system that can be used during creation of the help content for your application. It is very convenient while used inside of the IDE, but needs a special approach if used in the RCP. This article tries to gather the information which may be useful.

Adding Help Support

Basic preparations

As discussed in Eclipse RCP Book and RCP Articles, the help system is not a part of the RCP-Runtime and should be added separately. The question arises where to add at to? If you follow the best practices for packaging of RCP applications, you should have at least one product and the top level feature defined (See Rule 1 of Chapter 23 of Eclipse Rich Client Platform). The top level feature includes the branding plug-in (containing the product definition) and refer to other features (like org.eclipse.rcp, and your functional features). In order to add the help system, you need to add the org.eclipse.help feature in this list.

Platform help buttons

There are several predefined buttons (actions) you can use for calling the help system. These are:

  • Help Contents
  • Help Search
  • Dynamic Help

In order to activate them from your ApplicationActionBarAdvisor just call:

private IWorkbenchAction helpContentsAction;
private IWorkbenchAction helpSearchAction;
private IWorkbenchAction dynamicHelpAction;

protected void makeActions(IWorkbenchWindow window)
{
helpContentsAction = ActionFactory.HELP_CONTENTS.create(window);
dynamicHelpAction = ActionFactory.DYNAMIC_HELP.create(window);
helpSearchAction = ActionFactory.HELP_SEARCH.create(window);
register(helpContentsAction);
register(helpSearchAction);
register(dynamicHelpAction);
}

If you want to do the same declarative, you have to create commands that use the following actionDefinitionIds:

  • org.eclipse.ui.help.helpContents
  • org.eclipse.ui.help.helpSearch
  • org.eclipse.ui.help.dynamicHelp

The same ids are required for registration of key bindings (e.G. Ctrl + F1, Shift + F1, F1 on Win32). Apparently, since these actions adjust their status depending on the state of the system and the plug-ins installed, I could not figure out how to force them to be enabled, when installed in a declarative way. Since they are still provided as ActionFactory (which is legacy due to the changes introduced by new Command Framework), they should be further activated from the ApplicationActionBarAdvisor.

Context-Sensitive Help UI Integration

The Eclipse platform provides not only the help system, but also support the so-called Context-Sensitive Help (a very confusing name, because the context is only the widget, and not the data). In the following, it is shown, how the connection between the widgets and the help system can be established.

The big picture

The content already defined in the help system can be pointed at from various places in the your application using the so-called help contexts, which on one hand point to the places in the documentation and on the other hand can be assigned to widgets in the application UI.

Establishing contexts

In order to assign the help context to a widget the invocation of the method PlatformUI.getWorkbench().getHelpSystem().setHelp(Control control, String contextId); is used. The contextId is a full-qualified string constructed from the pluginId and the local context name. The context name should be unique for this plug-in (usage of non-unique ids leads to a merge of different subjects, which is a nice feature, but may be not desired). I prefer to create the convenience method for this invocation:

public class HelpUtil
{
public static void setHelp(Control control, String localContextId)
{
if (localContext == null || control == null) return;
PlatformUI.getWorkbench().getHelpSystem().setHelp(control,
Activator.PLUGIN_ID + "." + localContextId);
}
}

There are also methods for registration of other SWT widgets (Control, IAction, Menu, or MenuItem) in the help system, which can be handled by the overloaded version of the method. The invocation of the convenenience method usually looks like: HelpUtil.setHelp(composite, "newWizardPage") and should be invoked from the createControls() of the correponding element. Please note, that the “newWizardPage” is a local name, and the pluginId is added to it inside of the conveninece method. Widgets that do not get focus should not be assigned context ids, since they will never trigger a context-sensitive help

The declarative part

As usual in Eclipse, there is a declarative part, that connects the context ids, set up in the code with the help pages. The connection is established by a special XML file. In order for the platform to know, where to find the file, there is an extension point (org.eclipse.help.contexts), that you need to contribute to:

<extension point="org.eclipse.help.contexts">
<contexts file="contexts.xml" plugin="de.techjava.rcp.ui" />
</extension>

The file attribute specifies the full path to the XML file containing the context definition. The plugin attribute is optional and declares for which plugin the context definition applies. Please note, that if the plugin attribute is ommited, the context names used in the context definition file will be seen as local to the plugin they are declared in. For example, if you want to support the context-sensitive help in plug-in de.techjava.rcp.xyz then your in-code definition of the context should define full qualified context names like de.techjava.rcp.xyz.context1. Either you use the extension point (org.eclipse.help.contexts) in the plugin.xml of the de.techjava.rcp.xyz plugin.xml, or if you put the usage of the extension point into some other plugin (e.G. central for all help), you must provide the plugin attribute with value “de.techjava.rcp.xyz”. This issue is badly discussed in the help guide and is a little confusing. In the context definition file the contexts are defined as follows:

<contexts>
<context id="context1" title="My first context">
<description>This is a test context</description>
<topic href="path/context1.htm" label="Context1"/>
</context>
...
</contexts>

Wizards and Dialogs

Wizards are used with or without dialog.

The call of the Wizard#setHelpAvailable(true) shows the Help button.
The call of the WizardDialog.setHelpAvailable(true); shows the small sexy round Question button.

References


Eclipse RCP by default promotes the usage of a single application window with multiple views and editors inside. This default can be changed to multi-windowed application. The platform API offers several methods to operate with multiple application windows:

package org.eclipse.ui;
...
public interface IWorkbench ...
{
/**
* Retrieves the number of opened windows
*/
public int getWorkbenchWindowCount();
/**
* Retrieves the array of opened windows
*/
public IWorkbenchWindow[] getWorkbenchWindows();
/**
* Openes a new window with given perspective
*/
public IWorkbenchWindow openWorkbenchWindow(String perspectiveId,
IAdaptable input) throws WorkbenchException;
/**
* Performs a perspective switch in a given window
*/
public IWorkbenchPage showPerspective(String perspectiveId,
IWorkbenchWindow window, IAdaptable input)
throws WorkbenchException;
...

}

Using this API, opening of new windows seems simple. For example one could define a perspective, that is always opens in a new window.

Closing windows is generally performed by calling close method on the IWorkbenchWindow instance.

package org.eclipse.ui;
...
public interface IWorkbenchWindow ...
{
  /**
   * Closes the window
   */
  public boolean close();
}

Unfortunaly, there is no elegant way to find out which window are you in. A workaround which uses Eclipse internal API works fine for WorkbenchWindow, which is a standard platform implementation of the IWorkbenchWindow interface.

/**
 * Determines if the window is a root window
 * @param window a window to be checked
 * @return true, if the window is considered to be a root window
 */
public static int getWindowId(IWorkbenchWindow window)
{
// HACK: note this could change in future
  if (window != null && window instanceof WorkbenchWindow))
  {
    return ((WorkbenchWindow)window).getNumber();
  }
  return -1;
}

The initial application window gets the id 1. The lookup in the implementation reveals that the internal method finds the smalles unused positive number and assigns it to the newly opened window. If you do not want to rely on this algorithm, just hash the newly created windows by they ids.