Community
Participate
Working Groups
Add a mechanism for recording a sequence of user interface interactions, storing then in a file, and playing them back at a later time. File playback will be made available as an action for the benefit of cheat sheets and active help. [Platform UI]
Shouldn't this bug depend on bug 8519, bug 35949 and bug 57105?
See http://dev.eclipse.org/mhonarc/lists/platform-scripting-dev/msg00006.html for pointers to a bunch of related info and efforts.
Post 3.1
It seems to me that executing a script is very similar to 'redoing' a sequence of commands that have been 'undone'. Perhaps the scriping framwork could use the same 'command pattern' code used to implement Undo/Redo?
I see that TPTP and PDE UI tests have some way to record and play back user interface gestures, could any of that be used for implementing this feature?
PDE UI macro recorder/playback was written by us (by me, to me exact :-) and is the basis for this proposal. We would like to have a comprehensive solution that resolves the problems of script fragility that we encountered during the development of the initial solution.
Dejan, I did examine and played a lot with your code earlier this year. A major issue imho is the widget resolution at playback. There are a lot of lessons learned there with abbot in terms of finding widgets in a repeatable and reasonably safe way. In the PDE UI you rely on generated id which may not be re-created exactly in the same if UI changes occured, I think.
and I digged into the TPTP UI recorder code when it was released. The code looked to me as a derivative from the PDE UI test code from Dejan.
Including Ali in the conversation since he worked on the TPTP one.
I think a critical mass of the community push and converging ideas is gathering to start moving this item. You are right - PDE and TPTP code bases are 'sisters' (or should I say 'PDE's version is an older sister? :-). Our initial assesment implied that unless a component explicitly declares a set of commands it can record and play back, we are really recording calling 'internal APIs' (an oxymoron if there was ever one). I have proposal for Eclipse Automation almost ready but the hectic pace of Eclipse M4 is driving me into the ground. The moment we ship M4, I will give it more attention and publish it to start the lively discussion. Although we cannot commit to this topic in 3.2, we should start talking about it as soon as possible so that we can start working on it right after 3.2 GA.
Dejan contirbuted his code to TPTP, which I integrated with TPTP's test project. Philippe, in response to your widget resolving mechanism you might be interested in http://www.eclipse.org/tptp/test/documents/userguides/Intro-Auto-GUI.html#2.4.1 Thanks Curtis for adding me to this list.
Ali, we want to make Eclipse Automation built in very deep in the platform and have one set of rules that all follow. As you are making future plans, don't try to create a fully autonomous framework because the investment will not be worthwhile considering the support in Eclipse. Instead, plan on participating in the upcoming work so that we have one automation story that is hopefully inclusive enough to accommodate various use cases (including TPTP's).
See also the Dash/Monkey scripting effort described in various posts on http://eclipse-projects.blogspot.com and also on http://www.eclipse.org/proposals/dash/ . Adding Bjorn to the CC list. Eventually, I think there should be one unified scripting / macro / keydef / command / automation / recording / etc. framework in Eclipse. But it may take a while to get there so the various experiments are useful.
Absolutely. Experiments are important to understand the issues and problems and are encouraged. What I would like to discourage is an effort to define a comprehensive solution that would then be pushed down into Eclipse.
We may also take advantage of the upcoming EclipseCon to hold a BOF talk or a panel on the possible future shape of Eclipse automation.
*** Bug 251035 has been marked as a duplicate of this bug. ***
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
