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(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.
My goal is to have a model where parameters are "less" specific !
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 cannot see the advantage of keeping serialization logic in each
individual plugin.
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 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.
The general idea does not seem much different from my AbstractPlugIn
implementing new Recordable interface
to make parameters (Map) serializable.
Let me know what would be your interface...
>
>> 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 ?
Just an example to progress in a concrete way in the discussion. In this
example, you can see
how I used Recordable interface implemented in AbstractPlugIn to be abe
to persist the state
of the plugin in a macro.
If you see better ways to make plugins recordable may be you can explain
on this example so
that I can understand clearly your objections.
>> 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.
OK, I'm quite sure your point is interesting, but I don't understand yet
fully how I can take advantage of it.
Let me some time to study the code, or if you have a simple schema to
illustrate how you would implement
it...
>
>> 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.
Ya, you're probably right. I don't know why I thought that the macro
recording should take before one exit
the execute or the run method. I'll reconsider this point.
> 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.
OK. Why not in the same listener executing plugins and already
implemented in AbstractPlugIn ?
>
>> * 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.
I've no problem with that. I'm not in a hurry and I'm open to any
suggestion to improve the esign.
Just need to tell you a bit more about longer-term goal I have in mind
(see the end of the mail).
>
>>> ** (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.
OK, what would be the good place ?
>
>>> 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?
No, just started on my loca machine, nothing committed.
> 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?)
In the order, i'd love legacy plugins
- magically work (don't think it is possible without refactoring)
- work in interactive mode (as it works today) even when started from a
macro (my second implementation after discusison with you - did not test
much though)
- be deactivated if started from a macro (my first implemenation)
> 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.
Let me understand clearly what this new interface could improve compared
with the simple "Recordable" interface I currently added.
I understood there is a flaw in my design about how the system should
listen to plugin execution for macro recording.
I did not understand yet why "Recordable" interface could not fit the
need to persist any Recordable action (including plugin execution).
PlugIn manager would be a great feature to add. We must just keep in
mind that we have not much resources
and that by starting several big features depending on each others, we
take risks to achieve none of them.
> 3. what about cursortools, data loading and such. can the design include them
> properly?
My design already includes dataloading (hence my fix in
DataSourceFileLayerLoader). It is not very clean in the sense that
I've to test if recordable are plugins or loader at execution time.
Did not think about cursor tools yet :-(
> 4. should we really save macros to text file? why not simply keeping it in OJ
> state for a start?
I think it is important to be able to save macros in files. We do not
have to implement all the stuff right now,
but I think that persistence is important to have in mind (I tried to
persist SchemaViewer in a macro, and it
was a difficult but interesting challenge)
>
> as Stephan would say .. just my 2 cents ;).. ede
Thanks, and here is a bit more context about what I've in mind with
these new features :
My first idea was to implement a modeler able to define a complex
process made of
inputs, processes and outputs organized in a graph (we already have one
in Sextante).
To start, the process definition could be defined in a xml file, then in
a GUI.
Then I realized that a macro recorder could be a first step with some
differences :
+ take advantage of all the processes already defined through OpenJUMP UI
- macro-recorder is GUI dependant
When I started to think of a model for a process modeler, I get an
interface with "input
specification", "output specification" and "parameters", the later
defined as a Map<String,Object>.
For macro recording, I started from this point, considered that
input/output specifications were
not needed (already constrained by UI), and keep only the core concept :
a parameters map.
Maybe I'll come back to this idea of a modeler, so I keep in mind that
for each plugin, ideally,
I would like to have a low level gui-independant definition of the
process. The plugin should
call this process with parameters issued from the GUI.
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://p.sf.net/sfu/Zoho
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
