Skip to main content

Platform and Equinox API

Platform Changes

Compare/merge files using Generic Editor extensions To leverage the extensions for Generic Editor (syntax highlighting, hover...) when comparing files, you can now simply associate the org.eclipse.ui.genericeditor.compareViewer to the desired file content-types. This will automatically add to the compare view most extensions contributed to the Generic Editor.
<extension point="">
Extensible Quick Access content The Quick Access search (accessible with Ctrl+3 shortcut) now provides a new org.eclipse.ui.quickAccess extension point to contribute additional content.

Classes in package org.eclipse.ui.quickaccess have been made API for this use-case.

The following example shows how Run and Launch Configurations are made available in Quick Access:

<extension point="org.eclipse.ui.quickAccess">
   <computer class="org.eclipse.debug.internal.ui.quickaccess.RunQuickAccessProvider" name=""/>
   <computer class="org.eclipse.debug.internal.ui.quickaccess.DebugQuickAccessProvider" name=""/>

The computers implement the org.eclipse.ui.quickaccess.IQuickAccessComputer class, which is responsible for returning some org.eclipse.ui.quickaccess.QuickAccessElement.

Computers are only contributing when their host bundle is started, bundles will not be started automatically when querying Quick Access.

Type parameters on Beans and JFace databinding classes Type parameters have been added to relevant classes and methods in the org.eclipse.core.databinding.beans and org.eclipse.jface.databinding bundles. This makes code using these classes more explicit and clear and can help catching bugs in an early stage. These changes complete the effort to use generics to improve the databinding framework, which was started several years ago. If you use these databinding bundles you should be able to get rid of many raw type warnings which have been unavoidable for a long time.


// The BeanProperties.value method returns a IBeanValueProperty<Bean, String>
IObservableValue<String> nameModel =
    BeanProperties.value(Bean.class, "name", String.class).observe(bean);
// The WidgetProperties.text method returns a IWidgetValueProperty<Text, String>
IObservableValue<String> nameTarget = WidgetProperties.text().observe(textControl);

dataBindingContext.bindValue(nameTarget, nameModel);

The changes are fully binary compatible and no behaviour is changed.

Tips for using the typed databinding API

  • Using the UpdateValueStrategy.create method to create update strategies with a converter avoids the need to specify type arguments:
    dataBindingContext.bindValue(ageTarget, ageModel,
        UpdateValueStrategy.create(converter), null);
  • It is often easier to work out the types when sub-expressions are assigned to variables:
    UpdateValueStrategy<String, Integer> toModel = new UpdateValueStrategy><();
    dataBindingContext.bindValue(target, model, toModel, null);
  • New methods for creating typed versions of property objects have been added in some places:
    // Returns a IViewerValuePropert<Viewer, ModelObject>
  • Upgrading to Java 10 lets you use the var keyword, which avoids much of the verbosity of using property objects with type parameters:
    var text = WidgetProperties.text();

Note about typed property factory classes: To avoid causing compile errors for clients new versions of property factory classes that return typed property objects have been created. This applies for the following classes: WidgetProperties, ViewerProperties, BeanProperties and PojoProperties.

To start using these classes simply replace the import of the untyped factory classes by an import of the typed version.

Note about EMF Databinding: EMF Databinding has not been updated with type parameters. That can make it awkward to use EMF Databinding together with the generified databinding APIs. A good strategy for working around that is to create factory methods for EMF properties with generic types as their return values:

public static IValueProperty<ModelEObject, String> name(EditingDomain editingDomain) {
    return EMFEditProperties.value(editingDomain, ModelPackage.Literals.MODEL_EOBJECT__NAME);
Tooltip support for CommonViewers It is now possible to provide tooltips to CommonViewer via ILabelProvider.

To do this, two steps are necessary:

  1. Enable tooltip support for the respective viewer by setting the option org.eclipse.ui.navigator.enableTooltipSupport to true in the extension declaration, as in
    <extension point="org.eclipse.ui.navigator.viewer">
      <viewer id="org.eclipse.ui.example.cnf.viewer">
        <!-- ... -->
            value="true" />
  2. Contribute an ILabelProvider which also implements org.eclipse.jface.viewers.IToolTipProvider. The tooltip text can be provided by the method getToolTipText(Object element) following the same rules as getText(Object element). I.e., the non-null, non-empty string obtained from the highest-ranked label provider is used as the tooltip.
Wizards can now be non-modal New APIs have been added to WizardDialog to enable a wizard to be non-modal.

When a dialog is modal it means that the underlying window can not be used. Eclipse Wizard Dialogs are modal by default. There are cases where it is desired that the dialog is not modal but that the underlying window can be reached while the user is finishing the wizard. The following API methods are added to the JFace WizardDialog class.

  • public WizardDialog setModal(boolean modal)
  • public boolean isModal()

In addition, the following methods have been made public to allow full control over the shell style of the WizardDialog.

  • public void setShellStyle(int newShellStyle)
  • public int getShellStyle()

You can now use the following code:

WizardDialog d = new WizardDialog(shell, wizard);

or fluent

new WizardDialog(shell, wizard).setModal(false).open();

CSS attribute swt-lines-visible A new css attribute 'swt-lines-visible' is supported on Table and Tree widgets and is mapped to getLinesVisible().

For example: The value of this property is true if Tree.getLinesVisible() returns true, else the value is false.

SWT Changes

Dark mode support on Mac An SWT application on macOS 10.14 can now be launched in dark theme and all the controls are rendered with the native dark appearance. The application will automatically launch in the light or dark theme based on the System appearance (set in System preferences).

You need to launch the application with org.eclipse.swt.display.useSystemTheme=true system property to enable this behavior. The default value of this property is false.

Screenshot of an SWT application in dark theme:

swt application in dark theme

Display.Close and Display.Dispose events sent on GTK on logoff/shutdown Display.Close and Display.Dispose events are now supported on GTK on logoff/shutdown. This works on GNOME and XFCE (> 4.13) sessions. This brings Linux/GTK in line with the Windows and Mac implementations:
  • Display.Close can set the Event.doit to false to send a "not ready" hint to the session manager. However, the session manager will usually ignore this hint and continue logoff/shutdown anyway. The time limit imposed by the session manager is 1 second, so it is not suitable for showing the user any UI.
  • Display.Dispose lets you run any final cleanup, such as saving settings on exit. Also, any code you have after a while (!xxx.isDisposed()) loop will run now. The time limit imposed by the session manager is 10 seconds.

Previous Up Next

Back to the top