Community
Participate
Working Groups
During the Eclipse startup, it is very important for a plugin to get the workbench state since some actions can be done only after startup the Workbench. julien omondo
Could you provide a case where your plugin is being loaded but the workbench has not been started yet?
I also find it important to know if the workbench is starting. For example, I have an editor that warns the user via a warning dialog in its init (IEditorSite, IEditorInput) method if some condition is met. If I leave the editor open and restart the workbench, my editor is re-initialized and the warning dialog will show up again. I can (and did, until 3.0) avoid this by checking for Workbench.isStarting()...
Have you looked at the comments in Workbench, and the WorkbenchAdvisor class yet? Specifically the postStartup() method?
I looked at the comments and didn't find anything helpful. Are you implying to extend WorkbenchAdvisor and implement postStartup to be notified when the workbench has started? If so, the WorkbenchAdvisor in use is IDEWorkbenchAdvisor, passed to the Workbench constructor by IDEApplication, and there is no way to extend it and somehow tell IDEApplication to use an instance of my class instead.
Right, did you see the section in the R3.0 documentation called "Customizing the workbench" this will at least help clarify what WorkbenchAdvisor is and IWorkbenchConfigurer etc... , then you can decide if this works for you. If not have you considered moving your warning to a time when the editor is made visible instead of the init? My question would be if you did use the "isStarting()" method to discover whether the Workbench was starting, what did you do with the error? Fail silently or...
Regular plugins cannot replace or extend the WorkbenchAdvisor. Note that Workbench.isStarting() was an internal method, so the request to add something similar as API is an enhancement request. We'll need more details about your use case. To reiterate, you have a view that when created during a session can perform some logic immediately, but in the restart case it needs to wait until the rest of the workbench is up and running. Can you provide more details about what exactly it's checking for (other views? other workbench state?) There may be other workarounds, e.g. using the startup extension point, which runs after the workbench is restored; or doing the logic in a display.asyncExec, which wil get run after the event loop starts running (after the workbench is restored).
Use PlatformUI.isWorkbenchRunning()
Note this: private boolean runEventLoop = true; public boolean isRunning() { return runEventLoop; } PlatformUI.isWorkbenchRunning() returns true even though the workbench is not properly initialized.
There are currently no plans to work on this
I am using while(PlatformUI.getWorkbench().getWorkbenchWindowCount() == 0); as a workaround. This waits till the workbench is up and has atleast one window. Can this lead to any issues?
Just because the windows are up doesn't mean that initialization is done but it should generally be safe. I think Nicks suggestion of using the startup extension point is considerably safer. Generally guessing about state will get you into trouble somewhere.
I re-implemented postStartup() in the class I extended from workbenchadviser. Here, I set a static bool to true; Another thread polls for this value and does a thread.yield() until this is set.
Rather than creating Thread and then yielding them it might be easier to create a Job with a scheduling rule - that way no Thread is taken out of the Thread pool and deadlock issues are easier to avoid.
It might be even simpler to use Display.asyncExec or .timerExec instead of a thread and yield.
I m terribly new to eclipse/ Java, so i think i ll pick that advice. Thanks
Display.async results in a deadlock for me
If you are blocking in your async then you can deadlock. You should never block in the UI if at all possible.
(In reply to comment #12) > I re-implemented postStartup() in the class I extended from workbenchadviser. > Here, I set a static bool to true; > > Another thread polls for this value and does a thread.yield() until this is > set. My suggestion was to do this: public static boolean started = false; public void postStartup() { started = true; } somewhere else: // the following should only be done after the workbench is initialized properly Display.getDefault().asyncExec(new Runnable(){ public void run() { if (MyWorkbenchAdvisor.started) { // do what needs to be done } else { // wait 0.5 seconds and then check again Display.getDefault().timerExec(500, this); } } });
correct me if I am wrong.. Display.asyncExec is safe only if you are in the main thread?
(In reply to comment #19) > correct me if I am wrong.. > Display.asyncExec is safe only if you are in the main thread? wrong.
asyncExec is a no-op in the main Thread. If you lock on the UI Thread you can deadlock the UI - how you got to the UI Thread makes no difference.
(In reply to comment #21) > asyncExec is a no-op in the main Thread. Display.asyncExec won't run the given runnable immediately, it will delay it until the next time events are processed. This is true even if you are on the UI thread.
I'm actually finding some use cases for needing to know whether the workbench is in 'startup' mode or not - in particular because it affects how our editors get loaded. Can we reopen this bug? In the init (IEditorSite, IEditorInput) method, we do an asyncExec of some of our editor loading to make most of the UI appear faster. However, asyncExec behaves very differently during startup, in that all calls are delayed until the workbench is available. In this case, we have a deadlock issue: occasionally a client of our UI needs access to that information that we've asyncExec'd, so our normal course of action is to just run the display loop - however, when this happens during startup (since editors are restored during startup, this is very easy to reproduce), our asyncExec call didn't actually put anything in the display queue. I've looked at potential solutions that involve DisplayAccess to make a "privileged startup thread" that is allowed to post the asyncExec, and using the temporary preference to use 3.2 threading, but both get rather messy and cause other issues - we make use of ModalContext and progress dialogs here; as well, this area of our code is extensible, so clients can use syncExec and asyncExec. See bugs #178875, #182176, and #219913. Since this is a problem for both our Eclipse IDE integration as well as our RCP app, we can't override the workbench advisor or that stuff. The best way for us to fix this is to know what the workbench startup state is, and take different actions depending on that state. Our "API friendly" solution at the moment is to have something like this: public class WorkbenchState implements IStartup { private static boolean started = false; public void earlyStartup () { Display.getDefault ().asyncExec (new Runnable () { public void run () { started = true; } }); } public static boolean isStarted () { return started; } } However, it is much easier to just use !((Workbench)PlatformUI.getWorkbench ()).isStarting (); and it would be great if this was just part of the API...
Reopening. The use case makes sense to me.
New API in IWorkbench is released to HEAD.
