Community
Participate
Working Groups
I recently switched over from RCP activation (WorkbenchAdvisor#preUIStartup and postUIStartup) to osgi bundle activation. However, now I am missing the functionality of postUIStartup: Being able to do something when the Workbench is up and running. I noticed the Workbenchlistener which only provides events when the workbench is shutting down. There should be ways of getting notified when the workbench has been started, same as postUIStartup (which can not be used when you drop the plugins into an eclipse installation since eclipse is its own RCP app). Ben
Just to clarify, why is the early startup extension point (org.eclipse.ui.startup I believe) not what you want? Do you want to be notified when the workbench is running, but after your bundle has been activated (lazily)?
(In reply to comment #1) > Just to clarify, why is the early startup extension point > (org.eclipse.ui.startup I believe) not what you want? Do you want to be > notified when the workbench is running, but after your bundle has been > activated (lazily)? > Right, I can see the problem here. In a RCP integration (since my plugin gets activated anyways), I want a notification just like postUIStartup(), so I guess the startup extension point should work. However in Eclipse the situation is different: I only want to be notified when I was activated (in that case, if I was using the startup extension point, my plugin would be activated always iirc).
One way to do this is to post an asyncExec in the Bundle.start() method.
Can we still count on that - the launcher now spins the event loop?
You can count on it more than ever before because we delay asyncExecs until the Workbench is up and running. Previously, anybody opening a modal dialog while starting up (or just calling Display.readAndDispatch) could have caused trouble.
Sounds like exactly what I was looking for, great! Will give it a try and report back here.
Works fine! What I find weird is that a UIJob doesnt seem to get executed at all when started before the workbench is up and running.
That is because there is no display to async exec it. marking as WONTFIX as it appears we have all we need here.
(In reply to comment #8) > That is because there is no display to async exec it. > > marking as WONTFIX as it appears we have all we need here. > I see. Was just wondering, because using Display.getDefault().asyncExec() works fine.
Display.getDefault() is more dangerous to use as it is created before the workbench is running. It is also not necessarily the one created by your WorkbenchAdvisor. In your case it is working out for you because you happen to be running at a time when they are the same.
(In reply to comment #10) > Display.getDefault() is more dangerous to use as it is created before the > workbench is running. It is also not necessarily the one created by your > WorkbenchAdvisor. In your case it is working out for you because you happen to > be running at a time when they are the same. > Yeah, I know its dangerous to use and that's why I thought about using a UIJob which would take care. Is there a better way then?
UIJob is the preferred way. is the issue that you want to post a UI Job to run after the workbench starts?
(In reply to comment #12) > UIJob is the preferred way. is the issue that you want to post a UI Job to run > after the workbench starts? > I need to execute code that is guaranteed to be run when the workbench is up. In RCP I can use postUIStartup() for this. But thats not the preferred way to do, because my bundles should work in other RCP applications that I dont control (like Eclipse). Display.asyncExec seems to have this effect from the Bundle#start method, but its not preferred as it seems. UIJob is not started at all from the Bundle#start method (at least on my setup).
Yes you have it right. Lets reopen and rename. The issue is that UIJob currently aborts if the workbench display is not running. I think the place to do this is WorkbenchJob - the shouldSchedule should not block when the workbench is not running only the shouldRun. You could try this yourself by writing a job that subclasses UI Job and overrides shouldSchedule to return true.
Ben, I think this will work if you explicitly set the display on the UIJob. UIJob job = new UIJob... job.setDisplay(someDisplay); If you don't tell UIJob what display to use, it will try to use the Workbench display. If the workbench is not running it will not execute the runInUIThread method.
(In reply to comment #14) > Yes you have it right. Lets reopen and rename. > > The issue is that UIJob currently aborts if the workbench display is not > running. > > I think the place to do this is WorkbenchJob - the shouldSchedule should not > block when the workbench is not running only the shouldRun. > > You could try this yourself by writing a job that subclasses UI Job and > overrides shouldSchedule to return true. > Hm, I think this is a chicken-egg problem :). Bundle#start() will always be called before the Display is created, but I need a Display to actually do the asyncExec (same is true for the UIJob, so either solution wont work if someone tried to create a new Display afterwards). Since the default implementation of createDisplay in Workbench is using Display#getCurrent() first and would only create a new Display if that is NULL, its working. I guess a safe, but ugly, solution would be to start a Job that is rescheduled at a certain period to check if the workbench is up and running.
(In reply to comment #15) > Ben, I think this will work if you explicitly set the display on the UIJob. > > UIJob job = new UIJob... > job.setDisplay(someDisplay); > > If you don't tell UIJob what display to use, it will try to use the Workbench > display. If the workbench is not running it will not execute the runInUIThread > method. > Right, that explains why the UIJob is not executing. The general problem I am facing is still there though.
*** Bug 279969 has been marked as a duplicate of this bug. ***
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
> Right, that explains why the UIJob is not executing. The general problem I am > facing is still there though. You can use "workbench as an osgi service" https://bugs.eclipse.org/bugs/show_bug.cgi?id=293512 <?xml version="1.0" encoding="UTF-8"?> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="my.WorkbenchListener"> <implementation class="my.WorkbenchListener"/> <reference bind="bind" cardinality="1..1" interface="org.eclipse.ui.IWorkbench" name="IWorkbench" policy="static" unbind="unbind"/> </scr:component>
