Community
Participate
Working Groups
Created attachment 177318 [details] Sample e4 view contribution The e4 views can not be used in the Eclipse 4.0. Workbench processing assumes that all views are compatibility views (WorkbenchPage.java): CompatibilityView compatibilityView = (CompatibilityView) part.getObject(); To duplicate: - Launch Eclipse 4.0 with the atatched bundle - In the quick access (Ctrl+3) type "cont" and select view "Contexts" - See the ClassCastException at above line in WorkbenchPage
Created attachment 177319 [details] Exception stack
I am surprised this is showing up in Ctrl+3.
(In reply to comment #2) > I am surprised this is showing up in Ctrl+3. Looks like I'm throwing e4 stuff into the IViewRegistry. I...don't think we want that to happen.
IWorkbenchPage's showView(*) methods expect the returned part to be an IViewPart. e4 views don't even know about IViewParts as they're just POJOs so this won't fly. It also wouldn't make sense for a PartInitException to be thrown even if the e4 view actually came up. Hence, I would like to remove the code from ViewRegistry that populates itself with ViewDescriptors generated from e4 part descriptors. This would prevent the CCE from occurring (as the view will not show up in Ctrl+3) but really, how are people supposed to bring up e4 views in a 4.x workbench? Should the 3.x view handlers just delegate to the e4 handler (which would probably mean reverting bug 319050)? Ctrl+3 wouldn't be impossible to do as we'd just rewrite the code to process part descriptors instead of the view registry.
Perhaps we took the wrong tact with pure e4 views in 4.0/compat. Right now, our 4.0 system can only work with 3.x parts. We probably have 3 choices to go forward: 1) make e4 parts invisible to 4.0. You can slap them directly in the model, but can't see them from any of the compat API, like showView or the workbench page or view registry 2) leave them as pure e4 parts, but generate 3.x wrappers as they appear in the system. That means that they would generate a WrapperPart instead of a CompatibilityPart (with whatever else that might entail). 3) come up with a compat layer to e4 bridge that would allow the e4 part to exist more naturally within the compatibility layer PW
(In reply to comment #5) > 1) make e4 parts invisible to 4.0. (In reply to comment #4) > ... (as the [e4] view will not show up in Ctrl+3) ... Those don't seem to be viable options to me. Going this path means the developers can only use e4 to write RCP apps, not to extend Eclipse 4.0.
There is no line between a view and an editor (no, an MPart and an MInputPart doesn't count), I'm not sure this wrapper thing makes sense.
I looked at the attached bundle and the code from CVS today and the part seems to be functioning outside of the CCE that you get when you show the view. I will implement a fix to QA to prevent this CCE from occurring.
(In reply to comment #8) > I looked at the attached bundle and the code from CVS today and the part seems > to be functioning outside of the CCE that you get when you show the view. I > will implement a fix to QA to prevent this CCE from occurring. This has been fixed by bug 330558. This bug is still valid as there are/may be are other areas in the 4.x SDK where we want to remove the restriction of it solely handling 3.x parts.
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. If you have further information on the current state of the bug, please add it. 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.
This is a mass change to close all e4 bugs marked with "stalebug" whiteboard. If this bug is still valid, please reopen and remove the "stalebug" keyword.
