I am using the ability to add an Eclipse 4.x part to an Eclipse 3.x RCP application's perspective as described in the Vogella chapter on RCP migration. All is well, I can create an 4.x part and view it in a 3.x perspective.
I'd like to access the instantiated 4.x POJO (in my case it contains a Browser widget) and set some parameters for display (the browser URL). However when I try to probe the constructed ViewPart what I have to deal with is an E4PartWrapper object:
E4PartWrapper newPart =
window.getActivePage().
showView(ViewEclipse4x.ID,
String.valueOf(nextId),
IWorkbenchPage.VIEW_ACTIVATE);
I can see from the code that E4PartWrapper does contain the wrapped part, but I don't see a way to access this object.
Is there an alternative to accessing the 4.x POJO underlying the constructed 3.x ViewPart?
Thank you.
Carlos S. Zamudio
Sorry. I can see the MPart can be found using the PartService:
EPartService partService = (EPartService) viewSite.getService(EPartService.class);
MPart part = partService.findPart(partName);
Related
I have a DSL written in Xtext. In order to add custom content proposal, I have edited the MyDslProposalProvider class in the ui project. The new proposals are present when I debug the plugin in Eclipse, but not in the web editor, which is ultimately what I want. I want to set the custom proposals at a single place and all generated editors to use them. Is it possible to do that with Xtext?
As I had the same problem and struggled a little bit with the solution (as I would like to use both, Eclipse editor and Web editor) I would like to provide some more detailed feedback on a possible solution here, which worked well for me.
In my solution I did the following steps.
Implement a MyDslIdeContentProposalProvider in my.dsl.ide sub project extending from IdeContentProposalProvider, package my.dsl.ide.contentassistant (newly created); an example of such an implementation may be found here.
The implementation is not such convenient as at the well known UI proposal provider for Eclipse. I had to implement switch cases based on MyDslGrammarAccess elements instead of structural grammar elements like in the UI proposal provider. On the other hand, I have only one proposal implementation for all editor cases that way (DRY principle!).
Register the MyDslIdeContentProposalProvider at MyDslIdeModule in the same project (only with that it works already in the web editor).
def Class<? extends IdeContentProposalProvider> bindIdeContentProposalProvider() {
MyDslIdeContentProposalProvider
}
Register the new MyDslIdeContentProposalProvider and the forwarding class UiToIdeContentProposalProvider at the MyDslUiModule in the my.dsl.ui sub project. (That's what took the longest investigation as it cannot be logically derived.)
override Class<? extends IContentProposalProvider> bindIContentProposalProvider() {
return UiToIdeContentProposalProvider
}
def Class<? extends IdeContentProposalProvider> bindIdeContentProposalProvider() {
return JavaPOSConfigLanguageIdeContentProposalProvider
}
For an full example see here.
As I had implemented the MyDslIdeContentProposalProvider in the newly created package my.dsl.ide.contentassistant, this package has to be exported in the MANIFEST.MF file of the sub project my.dsl.ide (the subsequent 2 exports were already there). Otherwise i would get an an error Access restriction: The type is not accessible due to restriction on required project in the MyDslUiModule.
Export-Package: my.dsl.ide.contentassist,
my.dsl.ide.contentassist.antlr,
my.dsl.ide.contentassist.antlr.internal
That way it worked well for for both editors, Eclipse and web.
Thanks Christian again for the initial hint!
... If I could make a wish, I would like to have the same structural grammar element access in the MyDslIdeContentProposalProvider as we have it today in UI proposal provider.
you need to subclass org.eclipse.xtext.ide.editor.contentassist.IdeContentProposalProvider and bind it in YourDslIdeModule and YourDslUiModule. Then (in Xtext 2.13) you can use org.eclipse.xtext.ui.editor.contentassist.UiToIdeContentProposalProvider bound in YourDslUiModule to delegate to that in eclipse ui.
In our Eclipse RCP 3.7 application we have quite a few calls to PlatformUI.isWorkbenchRunning().
For example most of the calls are guards around Workbench API calls, along the lines of
`
if (PlatformUI.isWorkbenchRunning()) {
display = PlatformUI.getWorkbench().getDisplay();
} else {
display = Display.getDefault();
}
We're migrating now to Eclipse RCP 4.4 and I can't find the correct way to replace these calls with RCP 4 compliant code.
I'm guessing I should inject some service / component and use that, but which component? IWorkbench cannot tell me whether it's running or not.
I would expect it to be quite a common problem, but could not find a solution by googling. Anyone solved this already?
e4 does not currently run headless so there isn't really an equivalent.
For access to the Display you can use
Display.getDefault()
everywhere.
If you have a class derived from SWT Control available you can also use Control.getDisplay()
If you want to use the asyncExec or syncExec methods of Display you can use UISynchronize as an alternative:
#Inject
UISynchronize uiSynch;
uiSynch.asyncExec(runnable);
I am using JS Overlay objects in my GWT application. When Debugging the application, I am not able to see the value of Overlay object. Is it a limitation of Using GWT overlay objects.?
Is it because Overlay object is a native Object..? If it is a limitation, Is there any future plan to bring debugging support for Overlay objects in GWT.?
[I am not able to upload images. So typing what I see in the debug window]
> customer= JavaScriptObject$ (id=52)
> hostedmodeReference= JsValusOOPHM (id=183)
> value= BrowserChannel$JsObjectRef (id=188)
refId= 2
GWT version 2.5.1
Overlay types in GWT are a very special beast and are implemented using bytecode rewriting. See https://code.google.com/p/google-web-toolkit/wiki/OverlayTypes for (maybe a bit outdated) details.
As Suresh points out in the comments, there's low-level support for it in GWT but then IDEs have to use it for a seamless integration.
Pending that integration, you can use the utility class directly in the “watch” view (or similar) in your IDE during a debugging session:
com.google.gwt.core.ext.debug.JsoEval.call(MyJso.class, myJso, "myMethod")
This will print the json string from the JavscriptObject.
// Print it to the log
GWT.log(new JSONObject(customer).toString());
// Popup window
Window.alert(new JSONObject(customer).toString());
I'm trying to get the instance of a view part in an Eclipse e4 application but I can't find the PlatformUI class. Has the name changed since Eclipse 3 or is it located in a different package?
When looking at Eclipse e4 Parts:
bugs like 371405 can be instructive:
org.eclipse.ui.presentations
This API no longer works in 4.2, and we never intend to make it work.
It is incompatible with the pluggable rendering story in 4.2. Decisions that could once be made by the presentation extensions are now up to the renderer.
Affected API that needs deprecation:
Entire API package: org.eclipse.ui.presentations
Extension point:org.eclipse.ui.presentationFactories
org.eclipse.ui.IWorkbenchPreferenceConstants#PRESENTATION_FACTORY_ID
org.eclipse.ui.IWorkbenchWindowConfigurer#getPresentationFactory
org.eclipse.ui.IWorkbenchWindowConfigurer#setPresentationFactory
The rest of the Tutorial explains how to declare "parts" (editors or views)
The OP August Karlstrom mentions:
This used to work:
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().findView("some view");
Using a singleton like PlatformUI is a bad practice and one of the reason of the introduction, in e4, of Context. See this presentation on Context.
Paul Webster (IBM Eclipse Platform team member) comments:
In Eclipse4 you would use org.eclipse.e4.ui.workbench.modeling.EPartService.findPart(String) to find an MPart by ID.
The MPart contains the injected part in its object property.
As the page Workbench_Services details:
In e4, the notion of a workbench page will not be present.
The part service API will essentially be a merge of the existing 3.x IPartService and WorkbenchPage interfaces.
Note that this isn't ideal, as bug 372488 illustrates (following this thread):
An MPart for an MPartDescriptor is created with EPartService.createPart(descriptor_id), where descriptor_id is the identifier of the MPartDescriptor.
This part can be found again with EPartService.findPart(descriptor_id) -- if there is only one.
The problem is, that one may need do create more than one MPart for one MPartDescriptor.
An editor may be one example: one may want to edit different instances of one and the same kind.
The creation of more than one MPart for a given MPartDescriptor is possible, but there is no convenient method to find these parts.
EPartService.findPart(descriptor_id) will return the first MPart created for a particular MPartDescriptor, even if there is more than one.
So there are three problems, for a given MPartDescriptor:
EPartService.findPart(id) does not tell that there is more than one MPart.
There is no convenient way to get all MParts for this descriptor.
There is no API-way to get the particular MPart for given descriptor and "content" or "reference".
Currently the way to go is using EPartService.getParts() which unfortunately
returns all MParts, not only those corresponding to one particular
MPartDescriptor.
Then one would need to check, whether there is one MPart for the particular MPartDescriptor having a particular "content".
So something is missing that will find an MPart for a given MPartDescriptor
with particular "content" or "reference".
Just have the same question. After found this thread and tried with:
MPart mPart = epartService.findPart("MyPart");
MyPart myPart = (MyPart)mPart.getObject();
then I got my view part.
I'm using Netbeans. When I create a Java class, I sometimes want to change it to be a GUI component so that I can visually edit it using the GUI Builder.
What is the necessary step to transform a regular Java class to a GUI component so that Netbeans would recognize it and allow me to use GUI Builder ? (i.e. switch between Source and Design)
NetBeans' Gui builder, Matisse, works off a .form xml file located adjacent to the source file. Matisse creates and maintains the .form file and the code generator creates/updates methods in the java source to reflect changes to the form.
Unfortunately, there is no support in NetBeans for free-form GUI construction.
The closest I've seen is FormGenerator. It's a contributed NetBeans module that adds a right click action to .java files that will attempt to generate a .form file from the .java source. It's very limited, but it's better than nothing. It works best if you've followed the coding style employed by Matisse.
http://netbeans.org/projects/contrib/downloads/download/Readme.txt
http://netbeans.org/projects/contrib/downloads/download/FormGeneratorModule.zip
To add a class to the Palette, all that's needed is for your class to conform to the Java Beans model. That is, your class must:
be serializable
have a public, no-argument constructor.
All fields that have getter and setter methods that are named properly, i.e.:
int count
int getCount()
void setCount(int c)
should by default be recognized as a property.
For a finer control of what properties should and should not be exposed to the GUI Builder, you can associate your class with an implementation of the BeanInfo interface. See this Sun tutorial for more details.
However, NetBeans has several tools to help you in designing a custom bean. You can create new beans using the built-in templates available in the new file dialog, under the "JavaBeans Objects" folder.
This tutorial will guide you through creating an Image Bean.
What you could do is create one from scratch, design it as you wish, and then look at the generated code to understand how you can modify your existing class.
Try to use properties (Java bean!) for properties which should be changed from the ui designer and look here for more info.