Community
Participate
Working Groups
I'm trying to make the Riena framework run on the eclipse SDK 4.1.1 with the e4 compatibility layer, but it does not work. The method WorkbenchWindowAdvisor.createWindowContents(Shell) is not called by the WorkbenchWindow instance any more. The method is not deprecated and most of the other methods are still called. Was it just forgotten or is it not possible to provide the functionality with e4?
Jürgen, what is your current implementation of that method?
The source can be found here http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.riena/org.eclipse.riena.navigation.ui.swt/src/org/eclipse/riena/navigation/ui/swt/views/ApplicationViewAdvisor.java?view=markup&root=RT_Project Line 193+ We create the custom window layout for Riena in the method.
Jürgen, I've taken a quick look at the code but it's fairly complicated to grasp all at once. Could you perhaps provide a textural description of what the code is doing (and a screencap of how it looks on 3.8) ? There are likely two parts to this issue: 1) We aren't making the call..;-). I'll see if I can determine the correct location in Eclispe 4's startup life cycle to call it. 2) The actual SWT structure of the rendered window in Eclipse 4 is *very* different to that in 3.x since we now avoid what SWT calls the 'big lie' (where all parts and their toolbars etc are children of the WBW's shell, main toolbars are in a CoolBar...). Depending on whether you rely on the explicit 3.x widget structure or not the existing code may not work even once the call is being made...
Created attachment 205412 [details] Example Riena window Eric, we build a complete custom window, as you can see from the screenshot. We do not rely on the 3.x widget structure, because we build our own. :) In createWindowContents(...) we create a menu and cool bar, a custom content area and we setup a custom renderer for the header of the window.
My person opinion is that we can support the overloading of the WorkbenchWindowAdvisor#createWindowContents. My impression of WorkbenchWindowAdvisor is that it is more or less part of the Themeing-API which we can't support in Eclipse 4.x. I've not written the e4-renderers but people can do all sorts of nasty things in there and we'll never be able to support all they are doing in there. If people want to customize the WorkbenchWindow they need to provide their own renderer anything else is doomed to fail. I'd make the method final and document this API break like we did it with the rest of the presentation API, that's unfortunate but I think it is the only solution because as said we can't support all the things people do in there which is even worse than if we'd say simply document it. Jürgen if you need help on writing a WBWRenderer suited for Riena we could certainly help you.
(In reply to comment #5) > My person opinion is that we can support the overloading of the > WorkbenchWindowAdvisor#createWindowContents. > > My impression of WorkbenchWindowAdvisor is that it is more or less part of the > Themeing-API which we can't support in Eclipse 4.x. I've not written the > e4-renderers but people can do all sorts of nasty things in there and we'll > never be able to support all they are doing in there. > > If people want to customize the WorkbenchWindow they need to provide their own > renderer anything else is doomed to fail. > > I'd make the method final and document this API break like we did it with the > rest of the presentation API, that's unfortunate but I think it is the only > solution because as said we can't support all the things people do in there > which is even worse than if we'd say simply document it. > > Jürgen if you need help on writing a WBWRenderer suited for Riena we could > certainly help you. Come on, you make a method final that you never call ? Howabout @deprecating or removing it ?)
[...] > > Jürgen if you need help on writing a WBWRenderer suited for Riena we could > > certainly help you. > > Come on, you make a method final that you never call ? Howabout @deprecating or > removing it ?) Ok - looks like i missed that we are not calling it any more so then removing is the correct solution deprecating is certainly not because then one could assume that we are still calling it which will never ever happen.
Tom, thanks for your offer. Some help and pointers (examples, doc) would be great.
Ok - let's see. The problem is that we have no simplified API yet so you need to live with the very complex internal implementation: 1. The current implementation is found in org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer I think you should copy the class to an extra project 2. You need a custom WorkbenchRendererFactory so the best is probably to sublcass org.eclipse.e4.ui.workbench.renderers.swt.WorkbenchRendererFactory and overload the getRenderer() 3. You need to tell the rendering engine to use your IRendererFactory instead of the default one which can be done by specifying a property on the product- extension point like this: <product ..... > <property name="rendererFactoryUri" value="platform:/plugin/my.riena.renderer/my.riena.renderer.MyRendererFactory"> </property> </product> This was the easy part but should get you started. Now you need to specialize most likely the content found in your WBWRenderer-Compy "createWidget" and "processContents". E.g. I think you need an extra Composite so that you can plug in your title area, ... .
We do have to consider how to support the 3.x lifecycle. How important it is to call createWindowContents(Shell) depends on how much of a difference it makes if we circumvent it. Is it simply structural (the client area has no place to live)? Is it a huge glitch (our app now looks like it was dropped in a hole)? PW
(In reply to comment #10) > We do have to consider how to support the 3.x lifecycle. How important it is > to call createWindowContents(Shell) depends on how much of a difference it > makes if we circumvent it. > > Is it simply structural (the client area has no place to live)? Is it a huge > glitch (our app now looks like it was dropped in a hole)? > > PW As for Riena I can say, that if you switch the existing Riean from 3.x. to 4.x its like that "hole" you mention. You basically get an empty shell at best. We are currently working to improve that. I opened a new Bug 368147 that requests that API that does not work, is deleted from the codebase.
hi I also got this issue and i couldn't continue my project because of this.I recently upgraded the project(which was earlier in eclipse 3.2) to 4.1 to get the e4 tooling capability to reskin the UI. But unfortunately however i am stuck in this position and couldn't continue furthur.I couln't find any documentation or resources related to this issue.Could you please provide descriptive explanation on how to resolve this. regards
(In reply to comment #13) > hi AFAIK there is no workaround at this time, unless you re-implement the org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer in your RCP app. PW
I just ran into this issue when trying to upgrade a 3.7 application to 4.4 (with the need to use the compatibility mode because of the size of the application). Looks like we're setting up a menu bar and a status bar.
I am closing this as WONTFIX since it wont be fixed.
