Skip to content

Archive

Tag: Eclipse

galileo Finally, another annual release of Eclipse has arrived: version 3.5 aka Galileo.
Galileo is the release of Eclipse IDE synchronized with packets tuned for the Galileo release. Eclipse IDE has moved on from being a sole and mere development environment to being a rich architecture. Often, this is not visible to the novice user.

Galileo, or the JDT (Java Development Tools) to be more precisely, does not surprise with a load of stunning new features, instead, its a solid continuation of improvements. Concerning the JDT part, it has lost its pace of former days. But Eclipse JDT still is the reliable friend at your side, helping you code. This is a good thing, since Eclipse has been the IDE of choice for many, many Java programmers for a lot of years now and has grown to something like a “standard”. Its usability and reliability are well known and especially the first part has been constantly improved.

Galileo now draws its innovative power from the huge amount of different projects which were developed for it. The amount of tools for modeling is impressive. However it is not surprising, since modeling has become a sport in the past month. Consequently, it is bare logic to improve the tooling capabilities and quality. Galileo is following this path, not only because of Eclipse, but with what is available for it.

Code is poetry!

As announced in a previous post the Eclipse Demo Camp Hamburg – Galileo Edition took place in the East Hotel in Hamburg. Organized by Peter and Martin, the event was again an interesting meeting with Eclipse-interested people in a wonderful location. Five presenters introduced Eclipse and OSGi-related topics. Moritz Eysholdt reported about the (Meta)Model Evolutions, he was focusing on during his masters thesis. The interesting part of his solution are two Xtext DSLs for description of the Metamodel changes (EPatch) and model migration algorithms (MetaPatch). Heiko Behrens gave a funny and really good introduction of Xtext and DSLs for not Xtext developers. I really like his examples: these are simple and understanding for everyone. Great job! Marco Mosconi showed some ObjectTeams (black) magic. A very intersting technology using aspect-oriented programming for type-safe framework modifications. Seem to be pretty advanced technology with interesting tooling. Markus Alexander Kuppe had a talk on ECF and RFC 119 and gave some sneak preview of the upcomming features. Finally, I had a short talk on Common Navigator Framework, basically explaining the article posted here and something I documented for Galileo. Here are some visual impressions: my FlickR set and  Peter’s.

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…

EclipseDemoCamp The Galileo Edition of Eclipse is already in the pipeline and the community is happy to celebrate this with a series of events. In Hamburg we do it in two ways – there are Eclipse DemoCamps and Eclipse Stammtisch. This time Peter and Martin managed to put both events together. To make it short:

Hotel East If you want to attend, make sure you find a minute to write you name down in EclipseWiki. I suppose these kind of events is well-known. If you never heard of that – I can only recomend to take part. You will have the opportunity to listen to the talks, to speak with interesting people and get some news from Eclipse Commiters and Users. In the end you usually get some food and bevereges, to make the atmosphere a little more relaxed. The location is a very descend place with wonderfull flair. If you never be there it is worth to visit…

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

I found strange problem running wscompile (from Sun’s Java Web Service Developer Pack 1.6) inside Ganymede (Eclipse Version 3.4.1). The run of the wscompile Ant task produce a problem. The build script execution freezes on the wscompile task. It prints the following message on console but then nothing happens.

[wscompile] wscompile ...\env\java\1.4.2_03\jre\bin\classpath-classpath D:\workspaces\general\lib\bla.bo-0.0.1.jar; ... D:\workspaces\general\lib\... jar.0.5.5

In this line, the classpath of wscompile is printed.

The build script uses configured Apache Ant in version 1.6.5. I tried to start it with Java in versions 1.4.2 und 1.6.0.10. Both works in Europa (Eclipse 3.3.x) but don’t work in Ganymede (Eclipse 3.4.x), except for the first run. It seems that Ganymede provides a different handling for Ant scripts. Every first start of an Ant build script produces new “External Tool Configuration” (if not already there). If this configuration already exists, wscompile task doesn’t work!

This means my build script with wscompile task works only once, every first time after deleting the “External Tool Configuration”. I could live with that if I wouldn’t need that configuration. But I need that configuration to use different java version that is the workspace default.

Do anyone know how to fix that?
Here is my task definiton.

<taskdef name="wscompile"
		classname="com.sun.xml.rpc.tools.ant.Wscompile"
		classpathref="class.path.jwsdp"
		/>

and also task usage in the script

<wscompile fork="true" import="true" base="java/class" sourceBase="java/generated" verbose="true" features="documentliteral, wsi, searchschema, serializeinterfaces, explicitcontext" mapping="java/generated/META-INF/jaxrpc-mapping.xml" config="metadata/wsdl-config.xml" xSerializable="true">
	<classpath>
		<path refid="class.path.local" />
		<path refid="class.path.ant" />
		<pathelement path="${java.class.path}" />
	</classpath>
</wscompile>

Comments are welcome.


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.