[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] RE:[eclipse.org-architecture-council] E4 Summit preparation
|
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
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"
<mik@xxxxxxxxxxx>
Sent
by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
05/21/2008 02:21 PM
|
Please respond
to
mik@xxxxxxxxxxx; Please respond to
E4 developer list
<eclipse-incubator-e4-dev@xxxxxxxxxxx> |
|
|
To
| "'Oberhuber, Martin'"
<Martin.Oberhuber@xxxxxxxxxxxxx>,
"'eclipse.org-architecture-council'"
<eclipse.org-architecture-council@xxxxxxxxxxx>, "'E4
developer list'"
<eclipse-incubator-e4-dev@xxxxxxxxxxx>
|
|
cc
| mylyn-dev@xxxxxxxxxxx
|
|
Subject
| [eclipse-incubator-e4-dev] RE:
[eclipse.org-architecture-council] E4
Summit preparation |
|
> -----Original Message-----
> From: Oberhuber, Martin
[mailto:Martin.Oberhuber@xxxxxxxxxxxxx]
...
> 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
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
