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(Map<String,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 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>
ok, that's wrong: why would plugins register themselves? you'll have to touch
each and every plugin.
i can see you added it to AbstractPlugin and into some plugin's execute()
method. don't do that.
more legacy compatible and elegant is a listener implemented in your
MacroPlugin that can be registered in all the various places where plugins are
started.
> * I think macro can be application wide (ex. create a new task...)
why not.
>> * 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 !
nope, it's not just about "Detecting that the macro is recording".. a clean
reusable approach is needed here and i feel you went head on into hacking
without enough planning. i'd suggest we go back to a design stage and come back
with a better approach then. maybe we could implemet this feature together.
that'd be a first.
>> ** (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.
you added it to AbstractPlugin, where my contra arguments from above apply
plus.. not every plugin is extended from AbstractPlugin. it is simply the wrong
place to "record" plugin execution.
>> 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.
you didn't implement that so far? or did i overlook that?
generally i agree, that's my idea to - for automation we would need a new
selection plugin that selects by given parameters, hence imitates what a user
does in the GUI programmatically.
but.. if it shows a dialog or works with a saved parameter set should be up to
the user, like with the other plugins.
>> 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.
as i wrote above, let's take a step back and review the design and develop some
proper workflows we want to realize. i see some major problems here, which
makes it especially important to plan strategically and design healthy.
major problems from my side (just a quick list):
1. legacy compatibility (disable for old plugins or make it so they magically
work, is that even possible?)
2. legacy compatibility 2, how to design a possibility to load/save parameters
that
- is easily implementable by every plugin
- does not interrupt current functionality
- should this maybe go in a general PluginV2 interface development, where we
redesign the plugin framework even more generally wrt. a future with a plugin
manager that does download plugins from a repository.
3. what about cursortools, data loading and such. can the design include them
properly?
4. should we really save macros to text file? why not simply keeping it in OJ
state for a start?
as Stephan would say .. just my 2 cents ;).. 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=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
