Difference between revisions of "E4/Scripting"
|Line 1:||Line 1:|
Revision as of 09:45, 28 March 2012
- Cheat sheets?
- Quick macro editor?
- Short scripts to manipulate the IDE
- Scripting builds -- Implementing the workspace build
- Replace Core Expressions
- As a part of the language-independence story
- Simplify the process of writing new refactorings
- Lower the barrier to entry for plugin writers
- Avoiding class loading
- People get to work in their favorite language
- Throwaway programming
- Enabling Notes developers to script the environment
- Being able to bring in developers from other communities
- Checkout HEAD, run perf tests, Checkout HEAD-1, run perf tests, etc. until I found the perf regressions
- Scripting =?= easy
- Eclipse Monkey runs today against the workspace state
- Scala is already a first class citizen in the JVM runtime. We should exploit that.
- We also shouldn't let this capability make it impossible to use Rhino, etc...
- Is scripting the way we call across language boundaries where the language isn't a native JVM lanaguage?
- Important to extend Eclipse community around scripting languages
- Why do I need scripts? Why not just inject real Java into the running workspace?
- How do we handle threading?
- What if the macro loops forever? Does it block the UI thread forever? What is the answer?
- Having a DOM model representing/aggregating all model roots is useful for Java, not just for scripting.
- Today we can write a plugin that catches commands as they go by
- But you can't see model state
- Workspace context might be an issue here
- Do we record macros by screen scraping SWT events? At the level of Commands?
- Use case: Command recording lets you find out what the commands are for writing cheat sheets
- Challenge: Screen scraping SWT events has a hard time knowing if background jobs completed.