[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
|
[news.eclipse.tools] Re: workspace startup event
|
"Scott Stanchfield" <thetick-usenet@xxxxxxxxxxxx> wrote in message
news:9nib0m$40d$1@xxxxxxxxxxxxxxxx
> An idea...
>
> Perhaps we need a "scheduling" feature in eclipse. Users would have
complete
> control over it, scheduling how often certain features are executed.
(Could
> be startup, shutdown, every x minutes...)
Hmmm...perhaps we do. ;-) Among our corporate users, Task Scheduling was
the number one most popular feature in VA Assist. We have already received
more than a dozen requests to replicate that feature in Eclipse.
> Plugins that want to execute on startup could request this in their XML,
and
> when eclipse loads the first time with those plugins, the user could be
> informed.
Works for me. I don't mind if there is a positive action required on the
part of the user that enables the startup behavior as long as there is a way
to enable that startup behavior.
> The user would then be able to make an informed decision.
Hey, I'm all for informed decisions. What I don't like is not having the
option *at all*.
> As an example, in VA Assist, I never used its scheduling facility. So
having
> it run everytime I started VAJ was a resource waste for me.
Actually, if you didn't have any scheduled tasks, it didn't run. The task
scheduler only needs to be started if there is at least one schedulable
task. We plan to follow the same model in Eclipse as well.
> If presented with the above dialog, I'd say "no". Other folks like to use
> that facility to automate builds/exports/imports, and would definitely
> want to select "yes".
And, indeed, there are lots of folks like that out there, so I would suspect
that most of them would say "yes".
> A bit more complicated, but it really puts the responsibilities in the
right
> hands:
> * users must say "yes" to acknowledge they're taking a hit
> * plugin developers must consider what functionality could be disabled,
> and/or determine non-scheduled means of running their function
> * plugin developers would have to write extra specification (for
plugin.xml)
> to set up this function -- hopefully, extra work will discourage this
> practice, but it's still available.
All of which is fine by us. I'm glad to see you coming around to my POV. ;-)
-Eric