Perhaps it's not even so much of an issue.
>From a user's perspective, when I record e.g. an Excel macro,
I do expect some parameters (like the cell in which I started)
to be observed, but I'm 100% OK if a modification of my
table that has happened since recording the macro makes
the Macro run break.
Same for Emacs: If I record something, for instance
C-x ( down down C-x )
and then Replay this macro with C-x e at the end of
the file, I'm not surprised with the macro failing. Emacs
in this case prints a message saying
"macro operation was ended by a command ringing the bell"
Long story short, if the conditions under which a macro is
replayed have changed, users are typically prepared for
having the macro execution fail. Important point is only that
the palyback fails and stops, rather than going mad and
doing unwanted unexpected things like modify data unintentionally.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin
McGuire
Sent: Mittwoch, 21. Mai 2008 20:39
To: [EMAIL PROTECTED]; E4 developer list
Subject: Re: [eclipse-incubator-e4-dev]
RE:[eclipse.org-architecture-council] E4 Summit preparation
Re: parameter values going stale
Its a good point. Even aside from what can be captured via
undo, other things can always change outside of our view and control,
such as the state of the filesystem, things on other ends of network
connections, etc.
Perhaps a practical first usage case would be the ability to
generate cheatsheets as output from a macro recording mechanism. These
are parameterized, but typically the parameters are either quite simple,
or they trigger the prompting (e.g. for a file path). We have lots of
cheatsheets as examples of real parameterization. On a practical note,
it'd be a great way for folks to author cheatsheets!
Kevin
"Mik Kersten" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
05/21/2008 02:21 PM
Please respond to
[EMAIL PROTECTED]; Please respond to
E4 developer list <[email protected]>
To
"'Oberhuber, Martin'" <[EMAIL PROTECTED]>,
"'eclipse.org-architecture-council'"
<[EMAIL PROTECTED]>, "'E4 developer list'"
<[email protected]>
cc
[EMAIL PROTECTED]
Subject
[eclipse-incubator-e4-dev] RE: [eclipse.org-architecture-council]
E4 Summit preparation
> -----Original Message-----
> From: Oberhuber, Martin
[mailto:[EMAIL PROTECTED]
...
> Hi Mik,
>
> > * http://wiki.eclipse.org/E4/Commands#Mylyn_Monitor_API
>
> This sounds very exciting. What is your feeling, could the
> Mylyn interaction log be a strong enough technical base
> For macro recording & playback, also allowing manual text
> Edit of recorded scripts?
The interaction logging mechanism is sufficient for capturing
the state of
the workbench at the time that the action or command occurred.
So you get
the action ID, and could do things like encoding the parameters
into the
delta. You can also rely on the log having the state of the
workbench
(active editor, perspective and selection) since these would all
be
interaction events that would have occurred before the event.
For example,
the org.eclipse.mylyn.monitor.reports component has reporting
facilities
which can determine how much time each perspective was active
based on those
events.
In terms of using this for macro recording and playback, it
should be
sufficient as long as you did not need to capture any of the
resource
history. In other words, it would not be a good substitute for
the
Platform's undo mechanism. But for re-invoking commands it
should be
sufficient. I think that the main open question would be what
to do about
parameters. For example, if they're included in the replay,
you'd need to
worry about parameter values going stale. Note that we haven't
done any
work yet on capturing the parameter values, but considered it.
We've done some UI for replay of events for statistics recording
purposes.
We've done nothing along the lines of providing a view and
editing of this,
although the Izzet's Master's thesis that I pointed to on the
wiki entry
above did demonstrate some interesting UI in this area.
If you start exploring this just check out the
org.eclipse.mylyn.monitor.*
projects via one of our existing project sets, or consider
filing a new bug
for us to make a project set specific to that.
http://wiki.eclipse.org/index.php/Mylyn/Contributor_Reference#Workspace
If you have any specific questions either sign-up to the
mylyn-integrators
list or file a bug where we can discuss your requirements:
http://www.eclipse.org/mylyn/community/
Mik
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
