Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 357652

Summary:	[Compatibility] Allow model contribution to be merged into the model AFTER the compat layer
Product:	[Eclipse Project] Platform	Reporter:	Thomas Schindl <tom.schindl>
Component:	UI	Assignee:	Platform UI Triaged <platform-ui-triaged>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	emoffatt, ob1.eclipse, pwebster, remy.suen
Version:	4.1
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:	stalebug

Description Thomas Schindl

2011-09-14 11:49:32 EDT

We currently have the problem that model contributions made through our processors and or fragment.e4xmi are done before the compat layer has transformed plugin.xml and API-class into the model elements.

This makes the contributions fail because the target-id can't be found. There are 2 solutions to the problem:
a) We remember model elements we've not been able to merge into the model and 
   retry later on (e.g. based upon an event e.g. very short before the workbench 
   gets rendered)

b) We add an extra attribute to the contribution-elements to tell them that they 
   should be merged after the compat layer has done its job or we even better 
   provide another extension point from ui.workbench specifying the fragments to 
   contribute

Comment 1 Paul Webster

2011-09-14 12:28:44 EDT

We currently use classes like org.eclipse.e4.ui.internal.workbench.addons.CommandProcessingAddon

They create the model objects from the extension points.

PW

Comment 2 Eric Moffatt

2011-10-11 16:09:41 EDT

This seems to be a general issue in that we are using a combination of dynamic code modifications and / or translation of legacy extensions to manipulate the model.

I think that the current situation is that some of these changes take place after the 'initial' model has been rendered.

If we can clean up the life-cycle so that we can get the model into as complete a shape as possible before passing it to the rendering engine then we would also know where in the LC that we should move the model contribution code.

I see a possible issue here as well though...should we then be removing all model contributions on shutdown as well (or perhaps even better having the processor detect whether they're already there) ?

Comment 3 Eric Moffatt

2011-10-18 15:28:10 EDT

I'll take a look next milestone (think I'm full for this one...;-)

Comment 4 Paul Webster

2011-11-02 13:21:51 EDT

I think we need to think carefully about the Workbench startup, and who is responsible for what.

It seems to me that the Compatibility layer/Workbench should be responsible for creating and filling in the MApplication model to its pre-rendered state.  The compat layer then needs to provide hooks (in certain cases) as it needs to interleave compat layer behaviours throughout the rendering cycle.

Then that model should be passed to the E4Application for rendering, and the Eclipse 4 renderers need to be responsible for creating the SWT widgets.

PW

Comment 5 Eric Moffatt

2011-12-09 13:10:10 EST

Aggregate move to M5. Retarget to a different milestone if you wish...

Comment 6 Paul Webster

2012-01-11 09:18:24 EST

This is relevant to our Workbench Startup/E4Application startup discussion.

PW

Comment 7 Oleg Besedin

2012-04-12 11:32:00 EDT

(In reply to comment #6)
> This is relevant to our Workbench Startup/E4Application startup discussion.
> 
> PW

And bug 376486.

Comment 8 Eclipse Genie

2020-07-26 15:21:23 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.