[eclipse-scripting-dev] EASE ideas

[Christian Pontesegger <christian.pontesegger@xxxxxx>]

Hi group,

I had some time to think about next steps for the EASE project and I'd 
like to share some ideas with you.


About the script discovery:
================
Right now we use a dedicated nature for projects to be parsed for 
scripts. I was thinking of replacing this by registering URIs somewhere 
in a script discovery service. EASE already ships with a URI resolver 
for workspace:// URIs. Using such a URI would allow to not only register 
whole projects, but any kind of resource like subfolders or single 
script files. Besides we also could register local resources using 
file:// URIs, http, ftp or special things like 
platform://<plugin>/some/plugin/subfolder.
UPDATE: just learnt from Paul that the platform URI works on local 
resources too: https://bugs.eclipse.org/bugs/show_bug.cgi?id=420718

Registering scripts would also not change a project containing scripts. 
Right now, if we use a shared project (eg via git) a user adding the 
script nature would force all other users to have such scripts 
registered, too.


Script metadata:
==========
I would opt to decouple metadata from script source. Having that data in 
the header comment is nice for a first shot, but it will not work very 
well in teams. Users might want to rename script menus or change 
"enabledWhen" to their local needs. Having default data (on a first 
import) in the header is nice, but I would prefer to have it editable 
without touching the file content. (Which would not work anyway if the 
file is hosted on a remote server via http).

We also need a visual way of changing metadata: we could use the 
Properties view for that and use tabbed properties, which look quite nice.


Script service:
========
Now as we have script URIs and metadata we need to register them 
somewhere. I guess a service would be the right approach to do that. 
Either we can use the existing script service, create a new one or even 
use the preferences service to store configuration. Personally I favor 
the last approach as we could easily reuse stored data there to provide 
preference pages (eg for registered URIs).


Enabled when:
========
First I would like to rename it to visibleWhen, as this is, what it 
does: when the expression evaluates to false, the script is not visible 
in the context menu.
To edit such expressions I would love to reuse the editor we use for 
plugin extensions when we define activeWhen, visibleWhen, ... 
expressions. Not sure how easy it would be to reuse that forms editor 
page just for our certain usecase.


Attaching scrips to UI:
=============
Right now we can attach scripts to context menus. It would be great if 
we could also attach to toolbars and menus all over eclipse. Maybe we 
could reuse some parts of the discovery mechanism of the menu spy. Like 
"please click on the toolbar where you want to attach your script to".



please let me know what you think of this and add your ideas. If you can 
support on one or the other topic it would be even better!

regards
Christian