Community
Participate
Working Groups
While working on the synchronization between the E4 model and the JFace contribution framework, I am faced with some unclear semantics. Within the Eclipse E4 model, MMenuItems and MToolItems can only have one parent at the same time. EMF semantics ensure that this is always true, e.g., when an item is added to a new parent, it is automatically removed from its old parent. => Therefore, menu and tool items are always unique in the E4 model. In the JFace framework, IContributionManagers and IContributionItems are used. Although the IContributionItem interface has a setParent method (not a getParent), there is no guarantee or even an requirement that there is only a single parent. Also, the default ContributionManager implementation does no duplicate checking. Note that, checking that a IContributionItem has already a parent is not possible via its API. The derived implementations MenuManger and ToolBarManager do not do additional checking with respect to the unique usage of contribution items. => Therefore, in the JFace framework no assumptions can be made about how often an contribution item is used. However, there seem to be (incorrect) assumptions in the legacy code w.r.t. ownership of contribution items. It is assumed that the items are only used once and have a single parent, for instance for disposing unused items. For compatibility, the legacy menu and tool contribution items are synchronized to the E4 model. The current implementation assumes a one-to-one mapping. So for this did not result in real problems, but this is more luck or hidden by all kind of workarounds. While making the E4 model single source of information this results in all kind of problems. Now the real problem: Do we (1) allow the flexibility of the JFace framework to be used, or do we (2) require a strict single-parent relation. In case 1, the compatibility layer cannot make assumptions and will most likely become more complex and less efficient. Even placeholders for tool and menu items might be needed to get everything in place (this might need a model change) In case 2, the Eclipse usage of the JFace framework needs more strict checks. I don't know to what extend these interfaces are public or not. That is, if it is possible at all to get these restrictions in place. There might be some middle ground, in which we (3) do not support full mixing of E3 and E4 API. I hope this makes the problem a bit clear. Any feedback is appreciated. Note that there is already different behavior in 3.x and 4.x, e.g. see https://www.eclipse.org/forums/index.php/t/1102073/
