Holy cow. Thanks for the help, all. Zimbra's presented me with quite the sea of...
quotation-al soup.
Not sure if I'm doing the jbosstools-dev mailing list right. Here goes...:
Date: Wed, 15 Jul 2015 16:19:56 +0100
From: phantomjinx <p.g.richardson(a)phantomjinx.co.uk>
In addition to Display.asyncExec, you make want to put your code
inside a runnable, launched from
its own thread.
My reasoning:
The workbench can be started after some plugins have already been activated as such
getWorkbench().getActiveWorkbenchWindow() can be null even on the UI thread.
Consequently, I find
it prudent to create a polling thread that listens on getWorkbench().isStarting().
Thanks for your suggestion, Paul.
At what point am I guaranteed that there is an active workbench window?
Is it necessary to poll the workbench to see when it's active? Is it likely that
plugins crash otherwise?
Returns true then delay
Returns false then the workbench window should exist as well as the Display thread and
so
Display.asyncExec(addSelectionServiceRunnable) should be good to go.
Once control has been passed to the Display thread, the original
polling thread will finish and
disappear.
HTH
PGR
From: Denis Golovin <dgolovin(a)exadel.com>
Thanks for your response, Denis.
Ian,
Bundle.start() is always none UI thread.
I'm not entirely certain that Bundle is an ancestor of the class I'm referring
to.
The listener appears to be registered successfully when the plugin is run,
and it only has this problem in the context of SWTBot testing.
If the tool is targeting Eclipse 4
and up, you can try to use injection see details here
https://wiki.eclipse.org/Eclipse4/RCP/EAS/Workbench_Services.
Thanks for the link. The plugin also targets Eclipse 3 platforms, but I'll take a look
at this nevertheless
I can be more
specific if you could share your source code.
This is the PR that adds in the listener, and everything listener like:
https://github.com/eclipse/buildship/pull/120
Denis
From: "Max Rydahl Andersen" <manderse(a)redhat.com>
Thanks for your response, Max.
I think you need to look *when* you actually need the selection
listener
registered.
This is indeed something I'm doing right now. However, the UiPlugin seems to have a
pattern of
registering/unregistering listeners/services on start/stop. I'm hesitant to break that
pattern.
Normally it is not something to do at startup, but more when your gfx
part (editor/view etc.) gets created you need to start to listen.
I'll need to do a bit more reading on this one in order to see if it's a feasible
solution.
The selection listener seems to be fairly general. I'm still taking the time to
understand its purpose
and what the best solution is. For reference, this shows the earlier state of the code:
https://github.com/eclipse/buildship/pull/120/files
/max
From: Alexey Kazakov <alkazako(a)redhat.com>
Subject: Re: [jbosstools-dev] Quick SWT Question
To: jbosstools-dev(a)lists.jboss.org
Message-ID: <55A6948C.1000906(a)redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Agree with Max. But if you really need something general to listen to
everything you can use the early start up mechanism (see
org.eclipse.ui.IStartup). Your code will be invoked when the workbench
is initialized.
For example we use it in our usage to register a wizard listener to be
able to track all wizards in Eclipse.
I'm looking at this solution now. Is there any chance that the
'BundleActivator.stop()' method (the method that unregisters the listener, if it
hasn't already been unregistered) could be invoked before the 'earlyStartup'
method?