GSoC Project Introduction: More and Better Tests

[Adam Seskunas]

Hello Everyone,

My name is Adam Seskunas and I'm one of the GSoC contributors for
LibreOffice. My project, as the name suggests, is to write more and better
tests for LibreOffice. In particular, I will be focusing on writing filter
tests for writer.  The project will consist of two main parts, the first of
which will be to convert some JUnit tests to CppUnit, and the second part
will consist of writing missing unit tests.  A more detailed description as
well as a link to the project proposal can be found here
https://summerofcode.withgoogle.com/myprojects/details/pUU5JIpy

I'd like to take this opportunity to thank Hossein and Xisco for agreeing
to mentor me through the project. And I'd like to give a big thanks to
Ilmari for helping me get involved with LibreOffice over the past year and
encouraging me to apply for the GSoC. And last of all, a big thanks to all
of the community members, everyone has been welcoming and friendly, it's
been a very positive experience contributing to LibreOffice.

In the next week I will be working on refining the list of tests I will be
working on and gathering information about each test I plan to work on. In
my next update I hope to have a finalized list of tests to publish.

Adam Seskunas

GSoC Project Introduction - .NET Bindings for UNO

[Ritobroto Mukherjee]

Hello everyone,

I'm Ritobroto Mukherjee, one of the GSoC contributors for LibreOffice
this year. I'll be working on updating UNO bindings for .NET languages
(C#, F# and VB.NET).

This project aims to update the original .NET Framework compatible
bindings, to use the newer .NET 8 SDK. This would not only make them
cross-platform, but also allow us to introduce newer C# syntax and
features such as generic types. Tests, examples, documentation and a
NuGet package for end users to consume the bindings are also planned.

I am eager to work under the guidance of Mr. Hossein and Mr. Thorsten,
along with the support of the entire LibreOffice community. 

Similar to my peers, I'll be sending weekly updates shortly. Also a big
congratulations to all my peers who were also selected as contributors.

Best regards,
Ritobroto

Re: [Libreoffice-qa] GSoC project introduction

[Florian Reisinger]

Hi,

Just one small thought on top of this:

Groups / hirachy of actions are relevant:

This means:

- I inserted a picture, but this picture is not relevant. I want to delete
the picture and all the actions with the text.
  - The same is true for text formatting or changing things while being in
a dialog.

Being able to edit it is a big feature So from my POV:

Every element needs to have an ID and every action can depend on a other
action.

To keep it simple hirachy (which is the same as a depends on) might not be
necessary... But would be nice for grouping actions

>From my point of view a editor for the DSL would be required to ensure the
quality and expressiveness of the DSL.

Thanks for considering it.

Yours,

Florian

Terrence Enger  schrieb am So., 6. Mai 2018, 21:43:

> I am adding QA list to recipients, because I can foresee this work
> being useful in the preparation of bug reports.
>
> On Sat, 2018-05-05 at 15:14 +0530, Saurav Chirania wrote:
> > *Hello community!I am Saurav, an undergraduate from IIT Dhanbad, India.
> > I’ve been selected in this year’s GSoC to work with LibreOffice [1].I’ll
> be
> > working with the UI Testing framework. The first task will be to log the
> UI
> > actions in a log file according to a Domain Specific Language. Then, the
> > next task will be to automate the replay of the same actions using the
> > generated log file.I am ready with a fresh build of LibreOffice and am
> > currently browsing the relevant code parts to get more knowledge about
> the
> > different UI elements and how events work in LibreOffice.The timeline I
> > proposed in my GsoC proposal is at [2]. Suggestions regarding
> prioritising
> > of tasks, refining of the timeline or anything else to improve on are
> > welcome! You can contact me on the IRC channel #libreoffice-dev (nick:
> > chirania) or by sending me an email.Looking forward to an enjoyable
> > summer!Regards,Saurav Chirania[1] https://tinyurl.com/yba6cnpc
> > [2] https://tinyurl.com/ydgax9vk
> > *
>
> Whoopee!
>
> Please let me offer some random thoughts.
>
> I have often been unsure what I did to provoke LO to misbehave:
> sometimes my attention was absorbed by actual work I was doing,
> sometimes I had given up trying carefully to reproduce a bug report
> only to see the bug come up later.  So it would be good if the logging
> is cheap enough to use routinely during regular work.
>
> For a couple of reasons, I expect that the log file will not replace
> the STR in a bug report: (1) The log file will contain irrelevant
> operations, everything from a slip-of-the-fingers corrected promptly
> to completely different tasks imposed on the user during the LO
> session.  Determination of just which operations are relevant may be
> tedious, but confidence that the misbehaviour can be reproduced will
> justify much more effort than would mere knowledge that LO misbehaved
> once.  (2) Part of the QA process for bug reports involves testing
> older LO versions.
>
> From this, I conclude that it is important that the log file be
> decipherable.  Indeed, for the preparation of bug reports, the
> automated playback is mostly important for proving that the bug is
> reproducible, thus motivating the decipherment of the log file.  So,
> an easily readable log file is better than one which is hard to read,
> but the difference is less important than one might guess.
>
> If the log file is not easily readable, then we would eventually want
> a program to express it in user-level terms.  As a hack, this program
> might not be quite "easy", but it could be undertaken so that it would
> not hold up other work.  Perhaps it could be so specified that
> language-level programming knowledge (as opposed to knowledge of LO)
> would be sufficient for the task.
>
> Thank you, Saurav, for undertaking this work.  Is there a place where
> we can follow your progress?
>
> Terry.
> ___
> List Name: Libreoffice-qa mailing list
> Mail address: Libreoffice-qa@lists.freedesktop.org
> Change settings:
> https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

-- 

Mit freundlichen Grüßen, | Yours,
Florian Reisinger
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] GSoC project introduction

[Florian Reisinger]

Hi,

Just one small thought on top of this:

Groups / hirachy of actions are relevant:

This means:

- I inserted a picture, but this picture is not relevant. I want to delete
the picture and all the actions with the text.
  - The same is true for text formatting or changing things while being in
a dialog.

Being able to edit it is a big feature So from my POV:

Every element needs to have an ID and every action can depend on a other
action.

To keep it simple hirachy (which is the same as a depends on) might not be
necessary... But would be nice for grouping actions

>From my point of view a editor for the DSL would be required to ensure the
quality and expressiveness of the DSL.

Thanks for considering it.

Yours,

Florian

Terrence Enger  schrieb am So., 6. Mai 2018, 21:43:

> I am adding QA list to recipients, because I can foresee this work
> being useful in the preparation of bug reports.
>
> On Sat, 2018-05-05 at 15:14 +0530, Saurav Chirania wrote:
> > *Hello community!I am Saurav, an undergraduate from IIT Dhanbad, India.
> > I’ve been selected in this year’s GSoC to work with LibreOffice [1].I’ll
> be
> > working with the UI Testing framework. The first task will be to log the
> UI
> > actions in a log file according to a Domain Specific Language. Then, the
> > next task will be to automate the replay of the same actions using the
> > generated log file.I am ready with a fresh build of LibreOffice and am
> > currently browsing the relevant code parts to get more knowledge about
> the
> > different UI elements and how events work in LibreOffice.The timeline I
> > proposed in my GsoC proposal is at [2]. Suggestions regarding
> prioritising
> > of tasks, refining of the timeline or anything else to improve on are
> > welcome! You can contact me on the IRC channel #libreoffice-dev (nick:
> > chirania) or by sending me an email.Looking forward to an enjoyable
> > summer!Regards,Saurav Chirania[1] https://tinyurl.com/yba6cnpc
> > [2] https://tinyurl.com/ydgax9vk
> > *
>
> Whoopee!
>
> Please let me offer some random thoughts.
>
> I have often been unsure what I did to provoke LO to misbehave:
> sometimes my attention was absorbed by actual work I was doing,
> sometimes I had given up trying carefully to reproduce a bug report
> only to see the bug come up later.  So it would be good if the logging
> is cheap enough to use routinely during regular work.
>
> For a couple of reasons, I expect that the log file will not replace
> the STR in a bug report: (1) The log file will contain irrelevant
> operations, everything from a slip-of-the-fingers corrected promptly
> to completely different tasks imposed on the user during the LO
> session.  Determination of just which operations are relevant may be
> tedious, but confidence that the misbehaviour can be reproduced will
> justify much more effort than would mere knowledge that LO misbehaved
> once.  (2) Part of the QA process for bug reports involves testing
> older LO versions.
>
> From this, I conclude that it is important that the log file be
> decipherable.  Indeed, for the preparation of bug reports, the
> automated playback is mostly important for proving that the bug is
> reproducible, thus motivating the decipherment of the log file.  So,
> an easily readable log file is better than one which is hard to read,
> but the difference is less important than one might guess.
>
> If the log file is not easily readable, then we would eventually want
> a program to express it in user-level terms.  As a hack, this program
> might not be quite "easy", but it could be undertaken so that it would
> not hold up other work.  Perhaps it could be so specified that
> language-level programming knowledge (as opposed to knowledge of LO)
> would be sufficient for the task.
>
> Thank you, Saurav, for undertaking this work.  Is there a place where
> we can follow your progress?
>
> Terry.
> ___
> List Name: Libreoffice-qa mailing list
> Mail address: libreoffice...@lists.freedesktop.org
> Change settings:
> https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

-- 

Mit freundlichen Grüßen, | Yours,
Florian Reisinger
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: GSoC project introduction

[Terrence Enger]

I am adding QA list to recipients, because I can foresee this work
being useful in the preparation of bug reports.

On Sat, 2018-05-05 at 15:14 +0530, Saurav Chirania wrote:
> *Hello community!I am Saurav, an undergraduate from IIT Dhanbad, India.
> I’ve been selected in this year’s GSoC to work with LibreOffice [1].I’ll be
> working with the UI Testing framework. The first task will be to log the UI
> actions in a log file according to a Domain Specific Language. Then, the
> next task will be to automate the replay of the same actions using the
> generated log file.I am ready with a fresh build of LibreOffice and am
> currently browsing the relevant code parts to get more knowledge about the
> different UI elements and how events work in LibreOffice.The timeline I
> proposed in my GsoC proposal is at [2]. Suggestions regarding prioritising
> of tasks, refining of the timeline or anything else to improve on are
> welcome! You can contact me on the IRC channel #libreoffice-dev (nick:
> chirania) or by sending me an email.Looking forward to an enjoyable
> summer!Regards,Saurav Chirania[1] https://tinyurl.com/yba6cnpc
> [2] https://tinyurl.com/ydgax9vk
> *

Whoopee!

Please let me offer some random thoughts.

I have often been unsure what I did to provoke LO to misbehave:
sometimes my attention was absorbed by actual work I was doing,
sometimes I had given up trying carefully to reproduce a bug report
only to see the bug come up later.  So it would be good if the logging
is cheap enough to use routinely during regular work.

For a couple of reasons, I expect that the log file will not replace
the STR in a bug report: (1) The log file will contain irrelevant
operations, everything from a slip-of-the-fingers corrected promptly
to completely different tasks imposed on the user during the LO
session.  Determination of just which operations are relevant may be
tedious, but confidence that the misbehaviour can be reproduced will
justify much more effort than would mere knowledge that LO misbehaved
once.  (2) Part of the QA process for bug reports involves testing
older LO versions.

From this, I conclude that it is important that the log file be
decipherable.  Indeed, for the preparation of bug reports, the
automated playback is mostly important for proving that the bug is
reproducible, thus motivating the decipherment of the log file.  So,
an easily readable log file is better than one which is hard to read,
but the difference is less important than one might guess.

If the log file is not easily readable, then we would eventually want
a program to express it in user-level terms.  As a hack, this program
might not be quite "easy", but it could be undertaken so that it would
not hold up other work.  Perhaps it could be so specified that
language-level programming knowledge (as opposed to knowledge of LO)
would be sufficient for the task.

Thank you, Saurav, for undertaking this work.  Is there a place where
we can follow your progress?

Terry.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] GSoC project introduction

[Terrence Enger]

I am adding QA list to recipients, because I can foresee this work
being useful in the preparation of bug reports.

On Sat, 2018-05-05 at 15:14 +0530, Saurav Chirania wrote:
> *Hello community!I am Saurav, an undergraduate from IIT Dhanbad, India.
> I’ve been selected in this year’s GSoC to work with LibreOffice [1].I’ll be
> working with the UI Testing framework. The first task will be to log the UI
> actions in a log file according to a Domain Specific Language. Then, the
> next task will be to automate the replay of the same actions using the
> generated log file.I am ready with a fresh build of LibreOffice and am
> currently browsing the relevant code parts to get more knowledge about the
> different UI elements and how events work in LibreOffice.The timeline I
> proposed in my GsoC proposal is at [2]. Suggestions regarding prioritising
> of tasks, refining of the timeline or anything else to improve on are
> welcome! You can contact me on the IRC channel #libreoffice-dev (nick:
> chirania) or by sending me an email.Looking forward to an enjoyable
> summer!Regards,Saurav Chirania[1] https://tinyurl.com/yba6cnpc
> [2] https://tinyurl.com/ydgax9vk
> *

Whoopee!

Please let me offer some random thoughts.

I have often been unsure what I did to provoke LO to misbehave:
sometimes my attention was absorbed by actual work I was doing,
sometimes I had given up trying carefully to reproduce a bug report
only to see the bug come up later.  So it would be good if the logging
is cheap enough to use routinely during regular work.

For a couple of reasons, I expect that the log file will not replace
the STR in a bug report: (1) The log file will contain irrelevant
operations, everything from a slip-of-the-fingers corrected promptly
to completely different tasks imposed on the user during the LO
session.  Determination of just which operations are relevant may be
tedious, but confidence that the misbehaviour can be reproduced will
justify much more effort than would mere knowledge that LO misbehaved
once.  (2) Part of the QA process for bug reports involves testing
older LO versions.

From this, I conclude that it is important that the log file be
decipherable.  Indeed, for the preparation of bug reports, the
automated playback is mostly important for proving that the bug is
reproducible, thus motivating the decipherment of the log file.  So,
an easily readable log file is better than one which is hard to read,
but the difference is less important than one might guess.

If the log file is not easily readable, then we would eventually want
a program to express it in user-level terms.  As a hack, this program
might not be quite "easy", but it could be undertaken so that it would
not hold up other work.  Perhaps it could be so specified that
language-level programming knowledge (as opposed to knowledge of LO)
would be sufficient for the task.

Thank you, Saurav, for undertaking this work.  Is there a place where
we can follow your progress?

Terry.
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

GSoC project introduction

[Saurav Chirania]

*Hello community!I am Saurav, an undergraduate from IIT Dhanbad, India.
I’ve been selected in this year’s GSoC to work with LibreOffice [1].I’ll be
working with the UI Testing framework. The first task will be to log the UI
actions in a log file according to a Domain Specific Language. Then, the
next task will be to automate the replay of the same actions using the
generated log file.I am ready with a fresh build of LibreOffice and am
currently browsing the relevant code parts to get more knowledge about the
different UI elements and how events work in LibreOffice.The timeline I
proposed in my GsoC proposal is at [2]. Suggestions regarding prioritising
of tasks, refining of the timeline or anything else to improve on are
welcome! You can contact me on the IRC channel #libreoffice-dev (nick:
chirania) or by sending me an email.Looking forward to an enjoyable
summer!Regards,Saurav Chirania[1] https://tinyurl.com/yba6cnpc
[2] https://tinyurl.com/ydgax9vk
*
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice