On Thu, Oct 16, 2014 at 1:06 AM, <edgar.sol...@web.de
<mailto: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(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 !
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 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...
for a start the Recordable interface would need an additional
getParameters() method. this would allow to get the parameters
when/after running the plugin to save from outside.
but instead of this current approach i'd rather have the plugin
return a ParameterSet object, which could be the GUI component
enhanced by a ParameterSet interface. from an object oriented
standpoint the GUI is the parameter set, initially empty or with
default values, later on customized. how this is implemented
internally i leave aside for now in favor of the bigger picture.
>>
>>> 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.
maybe later. how plugins deal with it internally can be organized
after we agreed a interface model.
>>> 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...
it's just a hint on how the original JUMP authors added an
initially not planned feature
>>
>>> 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.
actually i see that you would need a static (only one instance in
OJ) macro recorder plugin that holds the status it is in. no need
for the blackboard here.
>> 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 ?
because AbstractPlugIn does not execute plugins. it is one or base
for lot's of them itself. it get's executed!
or what do you mean?
>>
>>> * 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
that's good :)
>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).
let's see..
>>
>>>> ** (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 one probably the wrapper that is used to make plugins into gui
elements. we could add a call to MacroRecorder there, which only
adds if execute() returns true.
>>
>>>> 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.
simply wrapping/extending the old plugin would allow to keep more
of old, proven working code.
>> 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)
i am not sure all is lost on that front. i'd really like to reuse
plugins as they are. or in other words - if we cannot realize
that, nobody will rework all our plugins. that's not going to
happen with the manpower we currently have. and even if i would
strongly oppose as this is a surefire way to introduce bugs over bugs.
> - 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)
you mean be deactivated if recording is active, so they cannot
even be added to a macro?
>> 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).
dunno what you mean. mainly the point is about, we are touching
plugin API so we should just keep in mind not to build in
obstructions for later.
also let's not cling to fixed interfaces right now. let's assume
we need to make plugins recordable and let's design it from top to
bottom, fro mthe big into the small, object oriented ;)
>
> 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.
right! that's why i started "small" with moving plugins into the
xml file and creating a unified way to install them. one step
towards adding/removing them programmatically.
>> 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.
yeah, my main objection again. not very clean. there _must_ be a
clean interface for automating plugins. so if we want to automate
e.g. OpenFilePlugin, we should use the same technique as for the
other plugins!
> Did not think about cursor tools yet :-(
right ;).. let's put the aside and say we disable them. after all
they are a very special very interactive case, maybe it doesn't
even make sense to automate them?
>> 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.
why?
>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)
the only reason for external files i see would be to exchange them
with other OJ instances/users. but if you really wanna do so you
will have to make sure that they are compatible with each other,
so you would have to go the extra mile and version them etc.
i simply don't see the need for that.
>>
>> 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.
>
ok, i see where you come from. and i see the discrepancy here.
plugins simply are a mere way to add functionality to OJ GUI..
that's what they were designed for.
if you wanna model processes you will probably have to introduce
something below plugins. maybe an object called Process, that has
some kind of reflection, in a way, so that you can ask it for
parameters it needs, can serialize it and of course run it under
the hood and it does whatever it is designed to do.
..ede
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push
notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
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
--
Er. Sukhjit Singh Sehra
Assistant Professor
Dept of Computer Science Engg.
Guru Nanak Dev Engineering College, Ludhiana, Punjab
Mobile No:- 09855959200
*In your free time kindly visit Sikh-relics.com - A Gallery of
Blessed Relics of Sikh Guru Sahib
------------------------------------------------------------------------------
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
