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);
Related
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);
I've been busily getting with the future and migrating an old eclipse 3.7 application over to Eclipse 4 and whilst I'm happy with the application model for porting all the views I have a number of source providers that I am unsure about porting wise. I've been using a few tutorials on Eclipse 4 including this Tutorial from good old Lars but none seem to cover this particular element.
For a small amount of Context my existing application has a few classes extending AbstractSourceProvider that are registered in the org.eclipse.ui.services extension point. My views register themselves as listeners to these services using the ISourceProviderService.getSourceProvider(key) function from the workbench and update themselves if that source fires a sourced changed event. I also have a few providers that reference each other some times too so I'm wondering if this will still work with injection.
What sort of model is used in Eclipse 4?, should I just use the same old extension point? Can these extension point services be injected in to the views in the new cool anotationy way?
What gives?
You can create a service in a number of ways:
Create an instance of your service class and put it in the IEclipseContext. This is often done in an 'Addon':
public class MyAddon
{
#PostConstruct
void postConstruct(IEclipseContext context)
{
MyService myService = ContextInjectionFactory.make(MyService.class, context);
context.put(MyService.class, myService);
}
}
The 'Addon' is declared in the application.e4xmi file.
You could also create the service like this in the LifeCycle class for the RCP.
An OSGi service will automatically be added to the Eclipse context.
You can use a Context Function which uses an OSGi service but doesn't create the actual service until it is needed.
In all cases you reference the service by injection:
#Inject
MyService myService;
Note that injection is only done on objects created by Eclipse from objects described in the application.e4xmi. It is possible to do injection on other objects using ContextInjectionFactory.
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 would like to know whether it is possible and good practice to report the progress of a org.eclipse.core.runtime.jobs.Job using a org.eclipse.swt.widgets.ProgressBar.
The javadoc says that the run method of org.eclipse.core.runtime.jobs.Job takes a org.eclipse.core.runtime.IProgressMonitor argument. However I don't want to use a jface ProgressMonitorDialog and I'd rather a non-dialog widget.
Can anyone please advise?
Have a look at org.eclipse.ui.internal.progress.ProgressManager, which extends org.eclipse.core.runtime.jobs.ProgressProvider to provide progress to Jobs. You can provide a ProgressProvider, and that can return your preferred IProgressMonitor for use with Jobs. You can base it on org.eclipse.jface.dialogs.ProgressIndicator or work with ProgressBar directly.
As mentioned by https://stackoverflow.com/users/9204/alexey-romanov in RCP you should use the IProgressSevice if possible, and you can display your progress in the ProgressView already provided in the workbench.
In an RCP application, the best practice is to use IProgressService.
I'm wondering is there a similar framework like Vaadin built on top of GWT which wraps the original GWT components but with server-side only event handling? (I know that Vaadin is built on top of GWT. I'm looking for an alternative solution.)
Vaadin is nice because of it's precompiled nature. I found compile times with GWT horrific the last time i've worked with it. Also it's a bit easier to maintain security if event handling code runs on the server. It would be nice if the standard GWT could be used in a similar way.
I don't think there is another like vaadin. and vaadin is already server-side..
see this http://vaadin.com/learn for more info
Have you seen this? - http://code.google.com/p/gwteventservice/
For server-side alternative, you might take at a look at ZK too.
Notice that its client side is based on jQuery, not GWT. However, you won't notice it at all since they both are server-side solutions and using pure Java.
Event handlers that you normally deal with are in server-side Java code. Consider this:
final Button testButton = new Button("Test Button");
testButton.addListener(new Button.ClickListener()
{
#Override
public void buttonClick(ClickEvent event)
{
mainWindow.showNotification("I am server-side code!");
}
});
As you said, you need to compile GWT code only when adding a custom component to your code. Vaadin's built in components are already compiled and put in the jar file. Although sometimes your IDE might detect your project as a GWT project and try to compile the widgetsets every time you change the code, when you might want to ask it to ignore.
If you look for alternatives to Vaadin you might have a look at Echo2.