[news.eclipse.tools] Re: workspace startup event

["Eric Clayberg" <clayberg@xxxxxxxxxxxxxxxxxx>]

"Jeff McAffer" <jeff_mcaffer@xxxxxxx> wrote in message
news:9nhd27$pdo$1@xxxxxxxxxxxxxxxx
>
> I must have missed the posts where you detailed the class of plugins you
are
> talking about.  Randy's action enablement case aside, I'm having trouble
> coming up with use cases that *require* plugin activation to be triggered
by
> installation.  I can see lots of people, as discussed, *wanting* their
> plugin to get activated on startup but you seem to be indicating something
> more fundamental.  Perhaps there are use cases we have missed?  Could I
> bother you to provide some concrete details?

Sure. There are a wide variety of potential IDE enhancements out there. Many
fall into the category of enhanced editors or other view-centric tools.
These tend to be "vertical" in nature and fit into the Eclipse model very
well. Just as many (if not more?) fall into a more broad, "horizontal"
category. These are enhancements that cut across or enhance *all* views and
basically represent enhanced IDE functionality commensurate with what is in
the base product. The quintessential example of this is our VA Assist
product that we did for VA Java (and which IBM awarded its 2001 Solutions
Excellence "Cool Tool" award). You can get an overview of its features
here...

    http://www.instantiations.com/assist/docs/default.htm

Now, many of those feature do fall into the enhanced or new view category
and won't be a problem implementing in Eclipse. We can implement them using
the Eclipse lazy-initialize model just fine.

Most, however, represent IDE-wide enhancements that are "active" all of the
time. The specific categories that I am concerned about relative to the lack
of startup hooks are general purpose TSR utilities and timer-driven /
scheduled utilities. The former generally require setting up event
handlers/listeners that are triggered when certain things happen in the IDE.
The latter require setting up a timer-driven event queue which will trigger
various tasks at specific intervals or in response to specific activities.
Neither of these categories play well in the view-centric model supported by
Eclipse. In order to be useful, both need to be active all of the time and
need to be "set up" during the startup phase of the entire system (no more
than a few milliseconds).

We don't need plugin activation to be triggered by installation (although
that would be nice), but what we do need is that once the user has taken the
active step of turning it on (via a properties page, etc.), that the plugin
will remain active until they turn it off. Since the plugin isn't
view-centric, it may not have any views open at shutdown that would trigger
activation on re-start later on.

Keep in mind that VA Java was (is?) the best Java IDE on the planet and,
yet, there was an almost limitless set of IDE-level enhancements that could
be made to it to make it even better. The same is equally true of Eclipse
and the products that IBM will layer on top of it. Until IBM someday builds
the perfect, ultimate IDE, there will be a market for the kinds of utilities
that I am talking about. This is really no different from any other open IDE
or OS out there including JBuilder, VisualStudio, VA Java, VA Smalltalk,
Macintosh, Windows, Linux, etc. All of those environments provide a way to
execute/install some code at system startup because they recognize that is
an absolute requirement for some products. By not supporting that basic
requirement, you eliminate an entire class of useful add-ons and/or run the
considerable risk of spawning a wide range of mutually exclusive
hacks/cheats, and, in the end, creating a much bigger problem for yourselves
than the problem which you *think* you might have.

-Eric