Hi,<div><br></div><div>Just one small thought on top of this:</div><div><br></div><div>Groups / hirachy of actions are relevant:</div><div><br></div><div>This means: </div><div><br></div><div>- I inserted a picture, but this picture is not relevant. I want to delete the picture and all the actions with the text.</div><div> - The same is true for text formatting or changing things while being in a dialog.</div><div><br></div><div>Being able to edit it is a big feature.... So from my POV:</div><div><br></div><div>Every element needs to have an ID and every action can depend on a other action.</div><div><br></div><div>To keep it simple hirachy (which is the same as a depends on) might not be necessary... But would be nice for grouping actions....</div><div><br></div><div>From my point of view a editor for the DSL would be required to ensure the quality and expressiveness of the DSL.</div><div><br></div><div>Thanks for considering it.</div><div><br></div><div>Yours,</div><div><br></div><div>Florian</div><div><br><div class="gmail_quote"><div dir="ltr">Terrence Enger <<a href="mailto:tenger@iseries-guru.com">tenger@iseries-guru.com</a>> schrieb am So., 6. Mai 2018, 21:43:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am adding QA list to recipients, because I can foresee this work<br> being useful in the preparation of bug reports.<br> <br> On Sat, 2018-05-05 at 15:14 +0530, Saurav Chirania wrote:<br> > *Hello community!I am Saurav, an undergraduate from IIT Dhanbad, India.<br> > I’ve been selected in this year’s GSoC to work with LibreOffice [1].I’ll be<br> > working with the UI Testing framework. The first task will be to log the UI<br> > actions in a log file according to a Domain Specific Language. Then, the<br> > next task will be to automate the replay of the same actions using the<br> > generated log file.I am ready with a fresh build of LibreOffice and am<br> > currently browsing the relevant code parts to get more knowledge about the<br> > different UI elements and how events work in LibreOffice.The timeline I<br> > proposed in my GsoC proposal is at [2]. Suggestions regarding prioritising<br> > of tasks, refining of the timeline or anything else to improve on are<br> > welcome! You can contact me on the IRC channel #libreoffice-dev (nick:<br> > chirania) or by sending me an email.Looking forward to an enjoyable<br> > summer!Regards,Saurav Chirania[1] <a href="https://tinyurl.com/yba6cnpc" rel="noreferrer" target="_blank">https://tinyurl.com/yba6cnpc</a><br> > <<a href="https://tinyurl.com/yba6cnpc" rel="noreferrer" target="_blank">https://tinyurl.com/yba6cnpc</a>>[2] <a href="https://tinyurl.com/ydgax9vk" rel="noreferrer" target="_blank">https://tinyurl.com/ydgax9vk</a><br> > <<a href="https://tinyurl.com/ydgax9vk" rel="noreferrer" target="_blank">https://tinyurl.com/ydgax9vk</a>>*<br> <br> Whoopee!<br> <br> Please let me offer some random thoughts.<br> <br> I have often been unsure what I did to provoke LO to misbehave:<br> sometimes my attention was absorbed by actual work I was doing,<br> sometimes I had given up trying carefully to reproduce a bug report<br> only to see the bug come up later. So it would be good if the logging<br> is cheap enough to use routinely during regular work.<br> <br> For a couple of reasons, I expect that the log file will not replace<br> the STR in a bug report: (1) The log file will contain irrelevant<br> operations, everything from a slip-of-the-fingers corrected promptly<br> to completely different tasks imposed on the user during the LO<br> session. Determination of just which operations are relevant may be<br> tedious, but confidence that the misbehaviour can be reproduced will<br> justify much more effort than would mere knowledge that LO misbehaved<br> once. (2) Part of the QA process for bug reports involves testing<br> older LO versions.<br> <br> >From this, I conclude that it is important that the log file be<br> decipherable. Indeed, for the preparation of bug reports, the<br> automated playback is mostly important for proving that the bug is<br> reproducible, thus motivating the decipherment of the log file. So,<br> an easily readable log file is better than one which is hard to read,<br> but the difference is less important than one might guess.<br> <br> If the log file is not easily readable, then we would eventually want<br> a program to express it in user-level terms. As a hack, this program<br> might not be quite "easy", but it could be undertaken so that it would<br> not hold up other work. Perhaps it could be so specified that<br> language-level programming knowledge (as opposed to knowledge of LO)<br> would be sufficient for the task.<br> <br> Thank you, Saurav, for undertaking this work. Is there a place where<br> we can follow your progress?<br> <br> Terry.<br> _______________________________________________<br> List Name: Libreoffice-qa mailing list<br> Mail address: <a href="mailto:Libreoffice-qa@lists.freedesktop.org" target="_blank">Libreoffice-qa@lists.freedesktop.org</a><br> Change settings: <a href="https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa</a><br> Problems? <a href="http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/" rel="noreferrer" target="_blank">http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/</a><br> Posting guidelines + more: <a href="http://wiki.documentfoundation.org/Netiquette" rel="noreferrer" target="_blank">http://wiki.documentfoundation.org/Netiquette</a><br> List archive: <a href="http://lists.freedesktop.org/archives/libreoffice-qa/" rel="noreferrer" target="_blank">http://lists.freedesktop.org/archives/libreoffice-qa/</a></blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p dir="ltr">Mit freundlichen Grüßen, | Yours,<br> Florian Reisinger</p> </div></div>