[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-scripting-dev] EASE ideas

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