Hi Benjamin,
One idea I had which may be related to the plugin management is
that OpenJUMP should be able to record plugin actions in macros.
Here's my basic idea.
void execute(Map<String, Object> macroOptions) {
Map<String, Object> optionsForExecute = null;
if (macroOptions) {
optionsForExecute = macroOptions);
} else {
optionsForExecute = Dialog.showAndReturnUserSelection()
// save optionsForExecute with MacroRecorder.
}
// use optionsForExecute to do something.
}
Yes, would be useful have possibility to pass options as a map instead
of taking it from Dialog.
What I was wondering is how to record and persist macros. There is a
nice macro recorder in jEdit which can record every action (plugin
action, menu action, key typing, mouse clicking... ) and record it as a
beanshell script which can be replayed at anytime. I never checked in
details what is the code behind this. Just thought in may be useful to
take such a need into account if a new design is decided for plugins.
Here are some greps listing all dependencies between source files and
jar-files in OpenJUMP.
http://pastebin.com/Npn26PKu
I played around a bit with it and ended up removing 50% of the
dependencies. The lend me to the idea of spliting OpenJUMP into
several jars: openjump-core.jar, openjump-scripting.jar (jython, bsh),
openjump-raster.jar (jai, ...), openjump-gml-svg-sld.jar (batik,
xml-apis) and openjump-postgis.jar (postgresql).
Nice work ! Separating jar with a openjump-core.jar which would not
depend on any other jar would be great. In the past, I introduced a
dependency to buoy. As it has not been largely adopted, the best would
probably to remove it now. I'll do it if we go this way. Hum, if I can
manage to find the necessary time...
I like the idea of keeping the core in Java and create a new project
file (thus a separate JAR-file) for the UI. The source code of the UI
could be in Java and Groovy.
I'm not very enthousiast about adding groovy to UI because as it is
architected today, UI is a necessary part of OpenJUMP and very
imbricated into it. But I can't see clearly where the separation of UI
and core is for you and what benefit you'll get using groovy for UI.
Some words to Groovy: Groovy acts the _same_ as Java (i. e. it
compiles to .class files), just without unneccessary ceremony. I use
it throughout my OpenJUMP extension (no single line is in Java). You
even can rename the extension of a .java file into .groovy and it will
compile fine (i. e. java syntax is actually a subset of groovy syntax).
Do you mean you use groovy as a compiled language and not as a scripting
language ? Have you got a small sample of a grrovy extension for OpenJUMP ?
Regards,
Michaël
Groovy can also used for scripting in applications (just like Jython,
JRuby or BeanShell). But I don't prefer to do that with Groovy.
--Benjamin
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
