Bug 365524

Description Bastian Roth 2011-12-04 10:23:42 EST

Build Identifier: 20110615-0604

Since I want to put some SWT controls on the palette, I cannot do this using the current palette implementation because it is based on GEF itself. As I can see, the only way to provide components like combo boxes, lists, text fields etc. on the palette is to re-implement them by extending Draw2D figures. But that is an laborious task and therefore I suggest to source out the concrete palette implementation from the EditDomain class.
My attached solution introduces a further EditDomain class called EditDomainWithPalette which then represents the base for the already existing DefaultEditDomain. For a successful outsourcing, the EditDomain class needs to become abstract because understandably the method loadDefaultTool() does not know how to determine the default tool. As from now, the concrete extensions of EditDomain shall ensure to implement this method (e.g. EditDomainWithPalette). Due to making EditDomain abstract, the class PaletteViewerProvider also needs to be adapted. In this class, every reference to EditDomain must be replaced with a reference to EditDomainWithPalette.
Of course with the proposed solution, the API of GEF 3.x breaks at some points. But I think that only few available projects are affected by this API evolution because every GEF project that I've seen so far is based on DefaultEditDomain, and not directly on EditDomain.

Reproducible: Always