Bug 301101 TrimmedPartLayout does not respect origin of client area
Currently the TrimmedPartLayout only respects width and height of the client area to layout the composites. The layout cannot expect that the client area is always located at 0,0 (even though in SWT most of the time it is). We should respect the location of the clientarea while computing the layout.
bundles/org.eclipse.e4.ui.workbench.renderers.swt/src/org/eclipse/e4/workbench/ui/renderers/swt/TrimmedPartLayout.java
/**
 * This arranges its controls into 5 'slots' defined by its composite children
 * <ol>
 * <li>Top: spans the entire width and abuts the top of the container</li>
 * <li>Bottom: spans the entire width and abuts the bottom of the container</li>
 * <li>Left: spans the space between 'top' and 'bottom' and abuts the left of
 * the container</li>
 * <li>Right: spans the space between 'top' and 'bottom' and abuts the right of
 * the container</li>
 * <li>Center: fills the area remaining once the other controls have been
 * positioned</li>
 * </ol>
 * 
 * <strong>NOTE:</strong> <i>All</i> the child controls must exist. Also,
 * computeSize is not implemented because we expect this to be used in
 * situations (i.e. shells) where the outer bounds are always 'set', not
 * computed. Also, the interior structure of the center may contain overlapping
 * controls so it may not be capable of performing the calculation.
 * 
 * @author emoffatt
 * 
 */
public class TrimmedPartLayout extends Layout {
	public Composite top;
	public Composite bottom;
	public Composite left;
	public Composite right;
	public Composite clientArea;
	/**
	 * This layout is used to support parts that want trim for their containing