<extension point="org.eclipse.compare.contentMergeViewers">
   <contentTypeBinding
         contentMergeViewerId="org.eclipse.ui.genericeditor.compareViewer"
         contentTypeId="org.eclipse.wildwebdeveloper.parent"/>
</extension>

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="%Run.name"/>
   <computer class="org.eclipse.debug.internal.ui.quickaccess.DebugQuickAccessProvider" name="%Debug.name"/>
</extension>

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.

Example:

// 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><();
  toModel.setConverter(converter);
  toModel.setAfterConvertValidator(validator);
  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>
  ViewerProperties.singleSelection(ModelObject.class)
  

• 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:

@SuppressWarnings("unchecked")
public static IValueProperty<ModelEObject, String> name(EditingDomain editingDomain) {
    return EMFEditProperties.value(editingDomain, ModelPackage.Literals.MODEL_EOBJECT__NAME);
}

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">
       <!-- ... -->
       <options>
         <property
           name="org.eclipse.ui.navigator.enableTooltipSupport"
           value="true" />
       </options>
     </viewer>
   </extension>
   

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.

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);
d.setModal(false);
d.open();

or fluent

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

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

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.

• 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.