Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Thoughts about ECF connection ui

Hi everyone,

>> > Also, what facility should provide auto-connect at startup? I
>> > personally think that auto-connect should have no dependencies on UI
>> > or wizards in particular (but a wizard should be able to specify that
>> > auto-connect should be used. (Note: I have no idea how it currently
>> > works, maybe it already is as I described?)
>> There is currently a 'startup' extension point in org.eclipse.ecf that
>> allows extensions to register themselves as having Jobs  to execute upon
>> ECF startup (the loading/start of the ECF core plugin).  Is this what
>> you mean?  The current connect dialog check box uses this mechanism and
>> I expect the new ones can/will as well.
> Some direct clarifications would be helpful as to whether you meant
> the workbench or ECF because there is a difference between the
> workbench starting and the ECF core starting.

I mean ECF core bundle org.eclipse.ecf (the one implementing the startup
extension point).

Actually, I was trying to talk to Erkki here. I shouldn't have quoted
your subsequent follow-up paragraph, sorry. :/ He had mentioned
"startup" so I wanted to check if he meant workbench, ECF core, or
OSGi (or something else entirely?) since the methods necessary to
perform an "auto-whatever" on its startup are different for each case.

Anyway, the point of my email was to explain to Erkki that the ECF
plug-in, assuming IECFStartup was used, is never going to start unless
you specifically set it so prior to booting up the framework, or by
manually activating it (say, through the OSGi console), or some other
means (through the UI examples I described previously, which in this
case the org.eclipse.ui.startup extension would probably be better).
There may be other ways to boot up a bundle, but unfortunately, I
don't know OSGi as well as I'd like.

I agree with Chris here in that the UI extension is probably
sufficient for our needs. When the new UI work begins, I think the
auto-connect stuff should be delegated to the ui startup extenson
point. In a headless framework-only context, the entry point (likely
the main(String[]) or start(BundleContext) method, or maybe even the
org.eclipse.core.products or org.eclipse.core.application extension
points?) of the application being run would probably perform all the
necessary initialization work anyway, so I think it is questionable as
to whether IECFStartup will be useful to developers at all.

Of course, I suppose I'm technically already wrong here since it seems
Erkki might have some use cases in a headless context for doing some
autoconnection work (assuming we're talking about ECF core startup).
So I guess my question is why run Runnable-ish-like stuff elsewhere
through extension points in a non-UI context when it's probably just
as easy to take care of it yourself within your own thread(s)? ECF
core, after all, doesn't really have anything interesting in my
opinion that warrants an "I must do this before the rest of ECF
activates"...besides maybe ContainerFactory?

If we do keep the startup extension, it'd probably be a good idea to
clearly indicate to the user when it will actually run and that there
is the org.eclipse.ui.startup extension point for UI business if the
user is actually trying to go that route.


Back to the top