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(Map<String,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 List<Recordable>)
- 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 List<Recordable>
* 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 plugin, but 2 execution modes (with or
without dialog). PlugIn is always recorded with the layername parameter,
but if executed in interactive mode, the layer or regex is asked to the
user and replaces the recorded name on the fly.
> do you catch my drift?.. ede
More or less. I'll go on with my implementation, and you'll tell me how
compatible
it is with you vision and how it can be improved.
Michaël
>
> ------------------------------------------------------------------------------
> 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=154622311&iu=/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=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
