Bug 163360 [Field Assist] - API - Provide ControlDecoration constructor without specifying decoration
Currently you can only create a ControlDecoration by specifying the control and the decoration in the constructor. This works nicely when the decoration is static (ie, always content assist). But there are use cases where the decoration changes depending on the state of the field, and at creation time, it's not clear which decoration will be set. Having a constructor that doesn't require a decoration would be nice.
bundles/org.eclipse.jface/src/org/eclipse/jface/fieldassist/ControlDecoration.java
* composite that parents the decorations and fields, and reserving space for
 * any decorations added to the field. ControlDecoration simply renders the
 * decoration adjacent to the specified (already created) control, with no
 * guarantee that the decoration won't be clipped or otherwise obscured or
 * overlapped by adjacent controls, including another ControlDecoration placed
 * in the same location. The tradeoff is one of guaranteed placement (via
 * {@link DecoratedField}) vs. more flexibility in creating the control, using
 * ControlDecoration, along with less concern for aligning decorated and
 * non-decorated fields.
 * <p>
 * Clients using ControlDecoration should typically ensure that enough margin
 * space is reserved for a decoration by altering the layout data margins,
 * although this is not assumed or required by the ControlDecoration
 * implementation.
 * <p>
 * This class is intended to be instantiated and used by clients. It is not
 * intended to be subclassed by clients.
 * 
 * <p>
 * <strong>EXPERIMENTAL</strong> This class or interface has been added as part
 * of a work in progress. This API may change at any given time. Please do not
 * use this API without consulting with the Platform/UI team.
 * 
 * @since 3.3
 * 
 * @see FieldDecoration
 * @see FieldDecorationRegistry
 * @see DecoratedField
 */
public class ControlDecoration {