Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[sukhjit sehra]

Respected Sir,

I am currently working on openjump topological plugin. i would be thankful
if you enlighten me by answering few doubts.:-

1. Why microsegments are removed, what if they are not removed from the
data.
2. The following text is from the topology tutorial
  The algorithm chooses those segment to be removed from the linestring or
polygon if the deformation is minimum  and will never removes the
micro-segments if it is located on the geometry boundary and if both
segments are strictly inside the linestring, But it removes the segment in
case interior angle is the closest to flat angle (180°).
3. How to handle if the vertex removed by algorithm is used by other
geometry. i.e what can be enforced on to it.


On Thu, Oct 16, 2014 at 1:06 AM, edgar.sol...@web.de wrote:

 On 12.10.2014 12:31, Michael Michaud wrote:
  Hi Ede,
  On 09.10.2014 22:33, Michael Michaud wrote:
  Hi,
  Macro recording an action on a selected layer :
 
  There is an interesting question about plugins executed on a
 selected layer
  or category (some are dialogless like delete or copy/paste)
  User starts a macro, delete selected layer A and stop the macro.
  What is the expected behaviour when the macro is run again ?
  - should it delete the selected layer (whatever its name is)
  - or should it delete layer A, regardless of whether it is
 selected or not.
 
  Use cases are welcome to try to define a behaviour both consistent
  and useful.
  as the plugin works with selected layers i'd expect the recorded
 plugin to work on a selected layer as well. this, of course, raises the
 question how to control selection during macro playing.
  Just thinking aloud about this problem...
  A solution could be
  - record the layer name (more information in the layer name than in
  selected layer option
  - choose named layer or selected layer (interactive mode) at
 execution
  time as a global option of the macro
 if interactive mode is chosen for each parameter named
 LayerName
  (or any other convention) open a
 MultiInputDialog to make the user choose the layer
  i work a lot with a music software professionally. this one and sound
 editors in general usually have an interface for plugins and these plugins
 have usually the possibility to save/load preferences of parameters you
 want to reuse.
  bearing this in mind, if you would now extend MultiInputDialog
  - GUI with a save/load function for parameters
  - a method call like we do for undoability
 
 context.getLayerManager().getUndoableEditReceiver().reportNothingToUndoYet();
  something along the lines of *
 
 context.getLayerManager().getMacroReceiver().saveProfile(mySettings);
  to save the used profile or none **.
  and the plugins with
  - a method e.g. execute(String 'profile') to run them
 programmatically with a given profile
  you could reuse this in your macro routines. another useful side
 effect would be that users were able to rerun plugins and load saved
 parameter sets sort of an half automation. in any way it has be up to the
 plugin to save/restore parameters as our current API does not have the
 capabilities to do that from outside the plugin.
 
  just an idea.. ede
  OK, I'm not sure I understand your proposition very well , but it does
  not seem to be too far from what I've started.
  Here after, I try to compare your ideas (what I understood) with what
  I've already done (did you have a look ?).
 
  One of the main point is to be able to serialize a set of parameters
  associated with a plugin.
  Seems that's what you call a 'profile'
  To make it as simple as possible, this is the role of my interface
  Recordable which has currently a unique
  setParameters(MapString,Object map) method.
  To serialize the map, I rely on java2xml (my idea is to reuse things
  like style serialization)
  i don't like the interface pretty much. as the parameters are plugin
 specific and can change between versions of the plugin i'd rather have the
 plugin save/load them. as the plugin GUI can be anything, not all plugins
 use MultiInputDialog, the essential code should be in the plugin to handle
 this.
  My goal is to have a model where parameters are less specific !

 what do you mean? they will always be very specific to the plugin that
 needs them.

  This way, the serialization/deserialization of parameters is made global
  (implemented in AbstractPlugIn
  only). It is absolutely independant from the use of MultiInputDialog.
  Note that in this model, the plugin
  save/load its parameters, but through a unified interface implemented in
  AbstractPlugIn only.

 i'd again say. the wrong place. an abstract class implements methods of
 the implemented interface with a default behaviour for developers to lean
 on and save effort this way. i don't see a default way to handle plugin
 parameters.

 what i could imagine is that you define a serialization interface for gui
 components to implement. if a plugin uses a gui component that implements
 this you could 

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[edgar . soldin]

On 12.10.2014 12:31, Michael Michaud wrote:
 Hi Ede,
 On 09.10.2014 22:33, Michael Michaud wrote:
 Hi,
 Macro recording an action on a selected layer :

 There is an interesting question about plugins executed on a selected 
 layer
 or category (some are dialogless like delete or copy/paste)
 User starts a macro, delete selected layer A and stop the macro.
 What is the expected behaviour when the macro is run again ?
 - should it delete the selected layer (whatever its name is)
 - or should it delete layer A, regardless of whether it is selected or 
 not.

 Use cases are welcome to try to define a behaviour both consistent
 and useful.
 as the plugin works with selected layers i'd expect the recorded plugin 
 to work on a selected layer as well. this, of course, raises the 
 question how to control selection during macro playing.
 Just thinking aloud about this problem...
 A solution could be
 - record the layer name (more information in the layer name than in
 selected layer option
 - choose named layer or selected layer (interactive mode) at execution
 time as a global option of the macro
if interactive mode is chosen for each parameter named LayerName
 (or any other convention) open a
MultiInputDialog to make the user choose the layer
 i work a lot with a music software professionally. this one and sound 
 editors in general usually have an interface for plugins and these plugins 
 have usually the possibility to save/load preferences of parameters you 
 want to reuse.
 bearing this in mind, if you would now extend MultiInputDialog
 - GUI with a save/load function for parameters
 - a method call like we do for undoability

 context.getLayerManager().getUndoableEditReceiver().reportNothingToUndoYet();
 something along the lines of *
context.getLayerManager().getMacroReceiver().saveProfile(mySettings);
 to save the used profile or none **.
 and the plugins with
 - a method e.g. execute(String 'profile') to run them programmatically 
 with a given profile
 you could reuse this in your macro routines. another useful side effect 
 would be that users were able to rerun plugins and load saved parameter 
 sets sort of an half automation. in any way it has be up to the plugin to 
 save/restore parameters as our current API does not have the capabilities 
 to do that from outside the plugin.

 just an idea.. ede
 OK, I'm not sure I understand your proposition very well , but it does
 not seem to be too far from what I've started.
 Here after, I try to compare your ideas (what I understood) with what
 I've already done (did you have a look ?).

 One of the main point is to be able to serialize a set of parameters
 associated with a plugin.
 Seems that's what you call a 'profile'
 To make it as simple as possible, this is the role of my interface
 Recordable which has currently a unique
 setParameters(MapString,Object map) method.
 To serialize the map, I rely on java2xml (my idea is to reuse things
 like style serialization)
 i don't like the interface pretty much. as the parameters are plugin 
 specific and can change between versions of the plugin i'd rather have the 
 plugin save/load them. as the plugin GUI can be anything, not all plugins 
 use MultiInputDialog, the essential code should be in the plugin to handle 
 this.
 My goal is to have a model where parameters are less specific !

what do you mean? they will always be very specific to the plugin that needs 
them.

 This way, the serialization/deserialization of parameters is made global 
 (implemented in AbstractPlugIn
 only). It is absolutely independant from the use of MultiInputDialog. 
 Note that in this model, the plugin
 save/load its parameters, but through a unified interface implemented in 
 AbstractPlugIn only.

i'd again say. the wrong place. an abstract class implements methods of the 
implemented interface with a default behaviour for developers to lean on and 
save effort this way. i don't see a default way to handle plugin parameters.

what i could imagine is that you define a serialization interface for gui 
components to implement. if a plugin uses a gui component that implements this 
you could then add an interface to the plugin that registers the main gui 
component which can then be asked for it's values.

 I cannot see the advantage of keeping serialization logic in each 
 individual plugin.

1. the advantage being that you don't have to worry about values at all, but 
only having the name of a profile to deal with.
2. no backward compatibility problems e.g. pluginauthor changes the name of a 
parameter internally
3. added value of profiles that users can reuse apart from macro framework

 Maybe I missed your point
 agreed, java2xml is a perfect choice to save settings.

 Now plugins must be able
 - to setParameters from a MultiInputDialog
 - to execute() from this map of parameters (your execute(String
 'profile') ?)
 That's where a big refactoring is needed for all plugins. Do your
 proposition can avoid 

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[edgar . soldin]

On 09.10.2014 22:33, Michael Michaud wrote:
 Hi,
 Macro recording an action on a selected layer :

 There is an interesting question about plugins executed on a selected 
 layer
 or category (some are dialogless like delete or copy/paste)
 User starts a macro, delete selected layer A and stop the macro.
 What is the expected behaviour when the macro is run again ?
 - should it delete the selected layer (whatever its name is)
 - or should it delete layer A, regardless of whether it is selected or 
 not.

 Use cases are welcome to try to define a behaviour both consistent
 and useful.
 as the plugin works with selected layers i'd expect the recorded plugin to 
 work on a selected layer as well. this, of course, raises the question how 
 to control selection during macro playing.
 Just thinking aloud about this problem...
 A solution could be
 - record the layer name (more information in the layer name than in
 selected layer option
 - choose named layer or selected layer (interactive mode) at execution
 time as a global option of the macro
   if interactive mode is chosen for each parameter named LayerName
 (or any other convention) open a
   MultiInputDialog to make the user choose the layer
 i work a lot with a music software professionally. this one and sound 
 editors in general usually have an interface for plugins and these plugins 
 have usually the possibility to save/load preferences of parameters you want 
 to reuse.
 bearing this in mind, if you would now extend MultiInputDialog
 - GUI with a save/load function for parameters
 - a method call like we do for undoability
   
 context.getLayerManager().getUndoableEditReceiver().reportNothingToUndoYet();
 something along the lines of *
   context.getLayerManager().getMacroReceiver().saveProfile(mySettings);
 to save the used profile or none **.
 and the plugins with
 - a method e.g. execute(String 'profile') to run them programmatically 
 with a given profile
 you could reuse this in your macro routines. another useful side effect 
 would be that users were able to rerun plugins and load saved parameter sets 
 sort of an half automation. in any way it has be up to the plugin to 
 save/restore parameters as our current API does not have the capabilities to 
 do that from outside the plugin.

 just an idea.. ede
 OK, I'm not sure I understand your proposition very well , but it does 
 not seem to be too far from what I've started.
 Here after, I try to compare your ideas (what I understood) with what 
 I've already done (did you have a look ?).
 
 One of the main point is to be able to serialize a set of parameters 
 associated with a plugin.
 Seems that's what you call a 'profile'
 To make it as simple as possible, this is the role of my interface 
 Recordable which has currently a unique
 setParameters(MapString,Object map) method.
 To serialize the map, I rely on java2xml (my idea is to reuse things 
 like style serialization)

i don't like the interface pretty much. as the parameters are plugin specific 
and can change between versions of the plugin i'd rather have the plugin 
save/load them. as the plugin GUI can be anything, not all plugins use 
MultiInputDialog, the essential code should be in the plugin to handle this.

agreed, java2xml is a perfect choice to save settings.

 
 Now plugins must be able
 - to setParameters from a MultiInputDialog
 - to execute() from this map of parameters (your execute(String 
 'profile') ?)
 That's where a big refactoring is needed for all plugins. Do your 
 proposition can avoid this refactoring in any way ?

i thought hard about this. but _No_, i see no way for interactive plugins to 
achieve reusable parameters without a plugin API change. not a very big deal, 
we can easily add an interface like the ones i already added (see 
AbstractPlugIn implements PlugIn, ShortcutEnabled, EnableChecked, Iconified).

this enhanced plugin would then be treated differently than our old plugins.

 Check the new BufferPlugIn and tell if you have ideas to avoid this big 
 refactoring...
 After this refactoring, you can use plugins
 - interactively getDialog() {setParameters()} - execute() or
 - in macro mode setParameters()/execute()

what exactly do you wnat me to check in BufferPlugIn ?
 
 I did not understand your example with getMacroReceiver, but maybe it's 
 an alternative to my implementation

yes, but in a design that is already implemented and proven working. 
undoability has the same issue of trying to add functionality that was 
obviously not implemented in the plugin API during design stage.

 of StartMacro/StopMacro/RunMacroPlugIn :
 - I put 2 objects in the workben blackboard* : a MacroStarted flag and 
 a Macro (a ListRecordable)
 - when a plugin is executed, before exiting, it checks if a macro is 
 being recorded (flag is on).
 If the macro recorder is on, the plugin is added to the ListRecordable

ok, that's wrong: why would plugins register themselves? you'll have to touch 
each and every plugin. 

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[Michael Michaud]

Hi,
 On 06.10.2014 13:28, Michael Michaud wrote:
 Hi,

 Macro recording an action on a selected layer :

 There is an interesting question about plugins executed on a selected layer
 or category (some are dialogless like delete or copy/paste)
 User starts a macro, delete selected layer A and stop the macro.
 What is the expected behaviour when the macro is run again ?
 - should it delete the selected layer (whatever its name is)
 - or should it delete layer A, regardless of whether it is selected or not.

 Use cases are welcome to try to define a behaviour both consistent
 and useful.

 as the plugin works with selected layers i'd expect the recorded plugin to 
 work on a selected layer as well. this, of course, raises the question how to 
 control selection during macro playing.
Just thinking aloud about this problem...
A solution could be
- record the layer name (more information in the layer name than in 
selected layer option
- choose named layer or selected layer (interactive mode) at execution 
time as a global option of the macro
 if interactive mode is chosen for each parameter named LayerName 
(or any other convention) open a
 MultiInputDialog to make the user choose the layer

Michaël


 ..ede

 --
 Slashdot TV.  Videos for Nerds.  Stuff that Matters.
 http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
 ___
 Jump-pilot-devel mailing list
 Jump-pilot-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel



--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[edgar . soldin]

On 09.10.2014 13:47, Michael Michaud wrote:
 Hi,
 On 06.10.2014 13:28, Michael Michaud wrote:
 Hi,

 Macro recording an action on a selected layer :

 There is an interesting question about plugins executed on a selected layer
 or category (some are dialogless like delete or copy/paste)
 User starts a macro, delete selected layer A and stop the macro.
 What is the expected behaviour when the macro is run again ?
 - should it delete the selected layer (whatever its name is)
 - or should it delete layer A, regardless of whether it is selected or not.

 Use cases are welcome to try to define a behaviour both consistent
 and useful.

 as the plugin works with selected layers i'd expect the recorded plugin to 
 work on a selected layer as well. this, of course, raises the question how 
 to control selection during macro playing.
 Just thinking aloud about this problem...
 A solution could be
 - record the layer name (more information in the layer name than in 
 selected layer option
 - choose named layer or selected layer (interactive mode) at execution 
 time as a global option of the macro
  if interactive mode is chosen for each parameter named LayerName 
 (or any other convention) open a
  MultiInputDialog to make the user choose the layer
 

i work a lot with a music software professionally. this one and sound editors 
in general usually have an interface for plugins and these plugins have usually 
the possibility to save/load preferences of parameters you want to reuse.
bearing this in mind, if you would now extend MultiInputDialog 
- GUI with a save/load function for parameters
- a method call like we do for undoability 
 context.getLayerManager().getUndoableEditReceiver().reportNothingToUndoYet();
something along the lines of *
 context.getLayerManager().getMacroReceiver().saveProfile(mySettings);
to save the used profile or none **.
and the plugins with
- a method e.g. execute(String 'profile') to run them programmatically with a 
given profile
you could reuse this in your macro routines. another useful side effect would 
be that users were able to rerun plugins and load saved parameter sets sort of 
an half automation. in any way it has be up to the plugin to save/restore 
parameters as our current API does not have the capabilities to do that from 
outside the plugin.

just an idea.. ede

* you will of course have to hack and register a MacroReceiver class capable 
for this that detects that a recording is running and saves the profile setting 
accordingly.
** (none would signal that the gui has to be shown on every macro run for the 
user to interactively input parameters, which would be legacy compatible for 
our old plugins.)

for GUI-less plugins (e.g. Copy/Cut/Paste ...) this would mean that we need to 
hack interactive versions of them and add a GUI to them which is shown during 
macro recording. for example - a new InteractiveCopySelectedItemsPlugIn 
replaces the old CopySelectedItemsPlugIn but wraps it and shows a gui when 
macro recording is on for users to specify a name or regex or just use the 
currently selected layers.

do you catch my drift?.. ede

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[Michael Michaud]

Hi,
 Macro recording an action on a selected layer :

 There is an interesting question about plugins executed on a selected layer
 or category (some are dialogless like delete or copy/paste)
 User starts a macro, delete selected layer A and stop the macro.
 What is the expected behaviour when the macro is run again ?
 - should it delete the selected layer (whatever its name is)
 - or should it delete layer A, regardless of whether it is selected or not.

 Use cases are welcome to try to define a behaviour both consistent
 and useful.
 as the plugin works with selected layers i'd expect the recorded plugin to 
 work on a selected layer as well. this, of course, raises the question how 
 to control selection during macro playing.
 Just thinking aloud about this problem...
 A solution could be
 - record the layer name (more information in the layer name than in
 selected layer option
 - choose named layer or selected layer (interactive mode) at execution
 time as a global option of the macro
   if interactive mode is chosen for each parameter named LayerName
 (or any other convention) open a
   MultiInputDialog to make the user choose the layer
 i work a lot with a music software professionally. this one and sound editors 
 in general usually have an interface for plugins and these plugins have 
 usually the possibility to save/load preferences of parameters you want to 
 reuse.
 bearing this in mind, if you would now extend MultiInputDialog
 - GUI with a save/load function for parameters
 - a method call like we do for undoability
   
 context.getLayerManager().getUndoableEditReceiver().reportNothingToUndoYet();
 something along the lines of *
   context.getLayerManager().getMacroReceiver().saveProfile(mySettings);
 to save the used profile or none **.
 and the plugins with
 - a method e.g. execute(String 'profile') to run them programmatically with 
 a given profile
 you could reuse this in your macro routines. another useful side effect would 
 be that users were able to rerun plugins and load saved parameter sets sort 
 of an half automation. in any way it has be up to the plugin to save/restore 
 parameters as our current API does not have the capabilities to do that from 
 outside the plugin.

 just an idea.. ede
OK, I'm not sure I understand your proposition very well , but it does 
not seem to be too far from what I've started.
Here after, I try to compare your ideas (what I understood) with what 
I've already done (did you have a look ?).

One of the main point is to be able to serialize a set of parameters 
associated with a plugin.
Seems that's what you call a 'profile'
To make it as simple as possible, this is the role of my interface 
Recordable which has currently a unique
setParameters(MapString,Object map) method.
To serialize the map, I rely on java2xml (my idea is to reuse things 
like style serialization)

Now plugins must be able
- to setParameters from a MultiInputDialog
- to execute() from this map of parameters (your execute(String 
'profile') ?)
That's where a big refactoring is needed for all plugins. Do your 
proposition can avoid this refactoring in any way ?
Check the new BufferPlugIn and tell if you have ideas to avoid this big 
refactoring...
After this refactoring, you can use plugins
- interactively getDialog() {setParameters()} - execute() or
- in macro mode setParameters()/execute()

I did not understand your example with getMacroReceiver, but maybe it's 
an alternative to my implementation
of StartMacro/StopMacro/RunMacroPlugIn :
- I put 2 objects in the workben blackboard* : a MacroStarted flag and 
a Macro (a ListRecordable)
- when a plugin is executed, before exiting, it checks if a macro is 
being recorded (flag is on).
If the macro recorder is on, the plugin is added to the ListRecordable

* I think macro can be application wide (ex. create a new task...)
 * you will of course have to hack and register a MacroReceiver class capable 
 for this that detects that a recording is running and saves the profile 
 setting accordingly.
Detecting that the macro is recording does not seem a big deal. Saving 
the profile is !
 ** (none would signal that the gui has to be shown on every macro run for the 
 user to interactively input parameters, which would be legacy compatible for 
 our old plugins.)
I see. Seems compatible with what I've started. I'll add the piece of 
code to run legacy plugin in interactive mode soon so that we can 
discuss this point more concretely as my implementation seems different 
from your line of code.
 for GUI-less plugins (e.g. Copy/Cut/Paste ...) this would mean that we need 
 to hack interactive versions of them and add a GUI to them which is shown 
 during macro recording. for example - a new 
 InteractiveCopySelectedItemsPlugIn replaces the old CopySelectedItemsPlugIn 
 but wraps it and shows a gui when macro recording is on for users to specify 
 a name or regex or just use the currently selected layers.
In my schema, we have only one 

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[Michael Michaud]

Hi,

Macro recording an action on a selected layer :

There is an interesting question about plugins executed on a selected layer
or category (some are dialogless like delete or copy/paste)
User starts a macro, delete selected layer A and stop the macro.
What is the expected behaviour when the macro is run again ?
- should it delete the selected layer (whatever its name is)
- or should it delete layer A, regardless of whether it is selected or not.

Use cases are welcome to try to define a behaviour both consistent
and useful.

Michaël

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[Larry Becker]

Hi Michaël,

  A bold new feature!  One question: are you considering the use of
BeanShell as the macro language?  This would multiply the power of macro
recording by making it a first step in script writing.

regards,

Larry Becker

On Mon, Oct 6, 2014 at 6:28 AM, Michael Michaud m.michael.mich...@orange.fr
 wrote:

 Hi,

 Macro recording an action on a selected layer :

 There is an interesting question about plugins executed on a selected layer
 or category (some are dialogless like delete or copy/paste)
 User starts a macro, delete selected layer A and stop the macro.
 What is the expected behaviour when the macro is run again ?
 - should it delete the selected layer (whatever its name is)
 - or should it delete layer A, regardless of whether it is selected or not.

 Use cases are welcome to try to define a behaviour both consistent
 and useful.

 Michaël


 --
 Slashdot TV.  Videos for Nerds.  Stuff that Matters.

 http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
 ___
 Jump-pilot-devel mailing list
 Jump-pilot-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[edgar . soldin]

good idea.. ede

On 06.10.2014 15:38, Larry Becker wrote:
 Hi Michaël,
 
   A bold new feature!  One question: are you considering the use of BeanShell 
 as the macro language?  This would multiply the power of macro recording by 
 making it a first step in script writing. 
 
 regards,
 
 Larry Becker
 
 On Mon, Oct 6, 2014 at 6:28 AM, Michael Michaud m.michael.mich...@orange.fr 
 mailto:m.michael.mich...@orange.fr wrote:
 
 Hi,
 
 Macro recording an action on a selected layer :
 
 There is an interesting question about plugins executed on a selected 
 layer
 or category (some are dialogless like delete or copy/paste)
 User starts a macro, delete selected layer A and stop the macro.
 What is the expected behaviour when the macro is run again ?
 - should it delete the selected layer (whatever its name is)
 - or should it delete layer A, regardless of whether it is selected or 
 not.
 
 Use cases are welcome to try to define a behaviour both consistent
 and useful.
 
 Michaël
 

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[edgar . soldin]

On 06.10.2014 13:28, Michael Michaud wrote:
 Hi,
 
 Macro recording an action on a selected layer :
 
 There is an interesting question about plugins executed on a selected layer
 or category (some are dialogless like delete or copy/paste)
 User starts a macro, delete selected layer A and stop the macro.
 What is the expected behaviour when the macro is run again ?
 - should it delete the selected layer (whatever its name is)
 - or should it delete layer A, regardless of whether it is selected or not.
 
 Use cases are welcome to try to define a behaviour both consistent
 and useful.
 

as the plugin works with selected layers i'd expect the recorded plugin to work 
on a selected layer as well. this, of course, raises the question how to 
control selection during macro playing.

..ede

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[Michael Michaud]

Hi Larry,

  A bold new feature!  One question: are you considering the use of 
BeanShell as the macro language?  This would multiply the power of 
macro recording by making it a first step in script writing.
I've thought about it (think it is doable), but I've not yet tried to 
implement it. Just started with plain xml.
Beanshell would have one drawback which could be raised by using groovy 
: all parameters will
need to be defined in Map (initialisation of maps is quite verbose in 
beanshell compared to groovy)


Michaël


regards,

Larry Becker

On Mon, Oct 6, 2014 at 6:28 AM, Michael Michaud 
m.michael.mich...@orange.fr mailto:m.michael.mich...@orange.fr wrote:


Hi,

Macro recording an action on a selected layer :

There is an interesting question about plugins executed on a
selected layer
or category (some are dialogless like delete or copy/paste)
User starts a macro, delete selected layer A and stop the macro.
What is the expected behaviour when the macro is run again ?
- should it delete the selected layer (whatever its name is)
- or should it delete layer A, regardless of whether it is
selected or not.

Use cases are welcome to try to define a behaviour both consistent
and useful.

Michaël


--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
mailto:Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel




--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[Michael Michaud]

Hi

 Hi,

 Macro recording an action on a selected layer :

 There is an interesting question about plugins executed on a selected layer
 or category (some are dialogless like delete or copy/paste)
 User starts a macro, delete selected layer A and stop the macro.
 What is the expected behaviour when the macro is run again ?
 - should it delete the selected layer (whatever its name is)
 - or should it delete layer A, regardless of whether it is selected or not.

 Use cases are welcome to try to define a behaviour both consistent
 and useful.

 as the plugin works with selected layers i'd expect the recorded plugin to 
 work on a selected layer as well. this, of course, raises the question how to 
 control selection during macro playing.
Yes, difficult question. I think it would be easier to rely on the layer 
name by default
(and it would make macro more independant from the UI),
But maybe it would be possible to add an option to switch from layerName to
selectedLayer during macro recording when it is really needed (the 
parameter value
would be changed from MyLayer to ${SelectedLayer} for example.

The question becomes even more complex with selected features...

Michaël


 ..ede

 --
 Slashdot TV.  Videos for Nerds.  Stuff that Matters.
 http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
 ___
 Jump-pilot-devel mailing list
 Jump-pilot-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel




--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[edgar . soldin]

On 06.10.2014 20:39, Michael Michaud wrote:
 Hi

 Hi,

 Macro recording an action on a selected layer :

 There is an interesting question about plugins executed on a selected layer
 or category (some are dialogless like delete or copy/paste)
 User starts a macro, delete selected layer A and stop the macro.
 What is the expected behaviour when the macro is run again ?
 - should it delete the selected layer (whatever its name is)
 - or should it delete layer A, regardless of whether it is selected or not.

 Use cases are welcome to try to define a behaviour both consistent
 and useful.

 as the plugin works with selected layers i'd expect the recorded plugin to 
 work on a selected layer as well. this, of course, raises the question how 
 to control selection during macro playing.
 Yes, difficult question. I think it would be easier to rely on the layer 
 name by default
 (and it would make macro more independant from the UI),
 But maybe it would be possible to add an option to switch from layerName to
 selectedLayer during macro recording when it is really needed (the 
 parameter value
 would be changed from MyLayer to ${SelectedLayer} for example.
 

maybe just another argument to have the macrorecorder create an editable script 
(beanshell, groovy ...) to allow users to finetune their macro.

..ede

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[edgar . soldin]

On 05.10.2014 17:57, Michael Michaud wrote:
 Hi Jumpers,
 
 I've started to add a big feature for OJ : capability to record macros.

that's really a nice feature! i like it..

without looking at the implementation details (you explained it pretty good), 
here some questions remarks. first and most important question:

are all non-interactive (dialogless) recordable now out of the box?

 I did not find a way to implement it without the need to revisit
 each plugin, but I tried to adopt a design
 - which does not break existing plugins
 - where adaptation to make a plugin recordable in a macro is minimal

what happens when during macro recording and a non-recordable plugin is 
executed?
 
 The general idea is :
 - make plugins persistable along with its parameters
 - make plugins runnable from a map of parameters (instead of
 an interactive dialog box)
 To achieve that in a simple way, plugins must be able to store/access
 their parameters through a simple MapString,Object
 
 Usually, to make a plugin recordable :
 - you must put parameters gathered from a MultiInputDialog into a map
 - refactor the code so  that it accepts the map values as parameters
 instead of named plugin attributes (see changes in BufferPlugIn)
 
 I have tested the concept with several different tools :
 - DisposeSelectedLayerPlugIn
 - BufferPlugIn
 - ViewSchemaPlugIn
 - DataSourceFileLayerLoader
 Some are easy to adapt (ex. DisposeSelectedLayerPlugIn), other
 are difficult (ex. ViewSchemaPlugIn)

i am pretty sure you had a specific use case in mind. could you post a simple 
step-by-step list of it that would illustrate a workflow that profits from 
automating?
 
 Any comment about the design is welcome
 Any help to make all our plugins recordable is welcome

that's my main issue with your approach. 
A. who is going to make at least most of our plugins recordable? shouldn't 
there be a mode where interactive plugins are allowed and come up with their 
respective dialog during automation?
B. our non-interactive plugins (e.g. Copy,Cut,Paste..) should be enabled by 
default, if they are not already by your current implementation.
C. users will assume that they can record _any: workflow when they use this 
feature, not just some enabled plugins. if we'd go down this road we should 
disable (via the Enabled interface) plugins that are not automatable during 
recording.

one implementation for C. could be a Plugin wrapper, that implements the Plugin 
interface and is instantiated given the original plugin. as _all_ our plugins 
are now installed via one routine we could easily wrap each plugin in this 
RecordableCheckedPlugin one during the startup.

RecordableCheckedPlugin could then implement
- an additional EnabledCheck which is enabled during recording and de/activates 
the plugin according to it's implemented interface.
.

just some quick thoughts ;).. ede

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)

[Michael Michaud]

Hi Ede,

Thanks for the feed-back
 On 05.10.2014 17:57, Michael Michaud wrote:
 Hi Jumpers,

 I've started to add a big feature for OJ : capability to record macros.
 that's really a nice feature! i like it..

 without looking at the implementation details (you explained it pretty good), 
 here some questions remarks. first and most important question:

 are all non-interactive (dialogless) recordable now out of the box?
Absolutely not.
When there is no dialog the adaptation is minimal (ex. 
DisposeSelectedLayerPlugIn).
Don't know if it can be reduced to nothing by adding some code in 
AbsractPlugIn
but the problem is that plugins with or without dialog have the same 
interface.

 I did not find a way to implement it without the need to revisit
 each plugin, but I tried to adopt a design
 - which does not break existing plugins
 - where adaptation to make a plugin recordable in a macro is minimal
 what happens when during macro recording and a non-recordable plugin is 
 executed?
Just ignored.
Until I add a piece of code at the end of plugin execution, the action 
is executed as before,
but not added to the macro.

 The general idea is :
 - make plugins persistable along with its parameters
 - make plugins runnable from a map of parameters (instead of
 an interactive dialog box)
 To achieve that in a simple way, plugins must be able to store/access
 their parameters through a simple MapString,Object

 Usually, to make a plugin recordable :
 - you must put parameters gathered from a MultiInputDialog into a map
 - refactor the code so  that it accepts the map values as parameters
 instead of named plugin attributes (see changes in BufferPlugIn)

 I have tested the concept with several different tools :
 - DisposeSelectedLayerPlugIn
 - BufferPlugIn
 - ViewSchemaPlugIn
 - DataSourceFileLayerLoader
 Some are easy to adapt (ex. DisposeSelectedLayerPlugIn), other
 are difficult (ex. ViewSchemaPlugIn)
 i am pretty sure you had a specific use case in mind. could you post a simple 
 step-by-step list of it that would illustrate a workflow that profits from 
 automating?
Not precisely. I know that OpenJUMP is efficient for prototyping or to do
one shot production, but that it has limitations to do repetitive tasks in a
production environment. :
Exemple (fictive)
- get a dataset from a partner
- tansform the schema
- join the data with our own data to keep data of interest only
- save or upload to a database

   
 Any comment about the design is welcome
 Any help to make all our plugins recordable is welcome
 that's my main issue with your approach.
 A. who is going to make at least most of our plugins recordable? shouldn't 
 there be a mode where interactive plugins are allowed and come up with their 
 respective dialog during automation?
There is a lot of work to make all plugins recordable but it can be done 
progressively.
I would have liked to find a way to make plugins recordable all at one 
time but there
is a great variety of implementations, and it seems difficult to me. For 
example, it
took me several hours to find where to implement my piece of code to 
make open
this shapefile recordable in a macro (not in a plugin).

Interesting question about mixing macro and dialog. From my point of 
view, macro
should not open dialog, but I can imagine particular cases where a 
dialog is needed.
It would add much complexity though.

 B. our non-interactive plugins (e.g. Copy,Cut,Paste..) should be enabled by 
 default, if they are not already by your current implementation.
I'll give more thought about it. Not sure that you can implement 
something working for these plugins
without interfering with other plugins as execute() may either
- do an action or
- open a dialog
I think if we implement a general method for non-interactive plugin (ex 
in AbstractPlugIn)
the side effect will be that dialog-based plugins will also be recorded 
and executed by opening
their dialog within a macro.
This behaviour maybe acceptable, and maybe easy to fix through a new 
abstract class or
interface to differenciate different kinds of plugins.
 C. users will assume that they can record _any: workflow when they use this 
 feature, not just some enabled plugins. if we'd go down this road we should 
 disable (via the Enabled interface) plugins that are not automatable during 
 recording.
Good point
 one implementation for C. could be a Plugin wrapper, that implements the 
 Plugin interface and is instantiated given the original plugin. as _all_ our 
 plugins are now installed via one routine we could easily wrap each plugin in 
 this RecordableCheckedPlugin one during the startup.

 RecordableCheckedPlugin could then implement
 - an additional EnabledCheck which is enabled during recording and 
 de/activates the plugin according to it's implemented interface.
Seems a good idea. Plugins should explicitely inherit their parent's 
EnabledCheck in this case.
It would also need to check-up/update all plugins or did I misses the 
point ?
 just