Hi! The scope of this may be different than what I understood, but if it isn't: doesn't the ECL language used in RCPTT already support many of the requirements? https://www.eclipse.org/rcptt/documentation/userguide/ecl/
best regards, Vlad On Thu, Jun 18, 2015 at 9:04 AM, Hallvard Trætteberg <[email protected]> wrote: > Christian, > > A quick comment on this, based on experience from a student who worked on > a similar problem. In his case (a smart Eclipse tutorial), he wanted to > recognize that a certain sequence of steps had been taken, and if not > provide means of doing it for the user. > > - Events can be thought of as lexical (keyboard and mouse), syntactic > (enter text, select item, click button) or semantic (invoke action or > command). The lexical and syntactic events often correspond to SWT's. It's > not always clear which of these you want in a specific case. Syntacic er > normally better than lexical, but you need to capture both and know how > lexical events where translated to syntactic by a widget. > > - Inputs occur in an input context (provide by previous output), and when > replaying you need to ensure the context is correct, e.g. has had time to > appear. This can partly be done by capturing widget life-cycle events, but > isn't easy. > > Even if Eclipse (SWT + JFace + the workbench) was built with this in mind, > it would be difficult. My personal conclusion after watching my student > struggle with making sense of the Display event stream, is that a UI > scripting DSL is needed for automation, rather than relying on capturing > events. It would have constructs for describing and waiting for output, > e.g. window with three labels and input fields, and input, e.g. enter text > in the second input field and click OK button: > > require output (waiting 10 seconds): > Window { > Label, TextField, > Label { text: "name"}, TextField is tf, > Label, TextField, > Button { text: "OK" } is ok > } > provide input: > tf.input("Hallvard") > ok.click > > With EMF, Xtext and Xbase it shouldn't be that difficult to make a > prototype... Some capture mechanism could be helpful for generating > fragments of such a script, but in general a person would need to validate > and most often edit it. > > It's certainly an interesting task. > > Hallvard > > > On 16.06.15 20:21, Christian Pontesegger wrote: > >> Brian, you are right. Also for mouse events it would be extremely hard >> to replay them. Just a small change to the perspective layout or timing >> constraints for eg popups would make it extremely hard to replay such >> macros correctly. What I am thinking of is a recorder that tries its >> best to figure out what a user does. so instead of recording a click on >> the file menu and afterwards a click on the Import... item I would like >> to map this to a command execution of the import action. >> This is an idea I am playing with for a long time without finding a good >> solution to this. Maybe there is none. However your key recorder is one >> step in the right direction. >> I will keep you informed when I start to play around with these things. >> >> Christian >> >> _______________________________________________ >> e4-dev mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/e4-dev >> > > -- > Hallvard Traetteberg, Associate Professor > Dept. of Computer and Information Sciences (IDI) > Norwegian University of Science and Technology (NTNU) > > _______________________________________________ > e4-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/e4-dev >
_______________________________________________ e4-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/e4-dev
