During recording, hooking on Evas functions can't work anymore as they
are no more invoked internally.
The new way to catch the events is to listen to them on the canvas.
Additionally, regular mouse events are now multi events whose tool (device id)
is 0, as well as key events with and without keycode are now always
considered with a keycode that can be 0.
Previous events catching has been kept to support legacy applications.
An issue that currently happens in Exactness is that we don't have any
way to debug the recordings.
Only debug information can help us to figure out what data is stored
inside the rec files.
Three commands are available:
- Clean: remove bad timestamp events and duplicate events
- Add a delay: because of the first event is directly treated if no
first timestamp is present, we need a way to fix recordings by adding
them a delay before the first event.
- List information: display the list of events, as vieet doesn't work at
all. Really helpful to figure out bugs.
An issue due to timing happens when applying scenarios on applications.
The first event is directly treated, even if the recorder waited a few
seconds without any action.
The reason is that Exactness saves in the .rec file a timestamp that is
the uptime value, i.e an absolute value. A better choice would have been
to save the number of ms relative to the launch of the application.
Because of this, Exactness doesnt have any way to know when the first
event has to be treated and consumes it whenever possible, i.e at the
beginning.
This patch adds to the recording file a timestamp reference, corresponding
to the uptime at ecore_init. When applying the scenario, this timestamp
is checked and gives an idea of a delay to wait before consuming the first
event.
This reverts commit 7989552b29.
This change introduces segfaults on my machine as well as Jenkins every time a
test fails and a comparison of the images is needed. We might want to bring this
back later but for now a working solution is preferred.
A lot of events caught by Exactness preload are repeated with the same
information, such as mouse move on the same coordinates and with the
same timestamp. This adds a lot of noise into the recording file.
This patch checks if the current caught event is the same as the last
stored and skips it if they are the same.
These two environment variables need to be forced to the standard
values to make sure scenarios are well applied.
Without this forcing, mouse clicks are not done at the right
coordinates, leading to a different behavior of the application. In
addition, shots comparison will always fail if the series of images are
based on different values of these variables.
This is useful when looking at recorded scenarios to understand what is
done.
Sometimes, when scenarios are too old, click is not done on the right
area, leading to weird behavior.
During ecore_shutdown, when the refcount reached 0, the scenario record
has to be done. The problem is that the ecore termination never happens
because of ecore modules loaded during init that references ecore
refcount.
The solution, until this is fixed, is to trigger the scenario recording
from a key press.
Summary:
Currently genlist_group is also running in play step even if it is
commented in tests.txt. Fixed this issue
Signed-off-by: kabeer khan <kabeer.khan@samsung.com>
Reviewers: cedric, stefan_schmidt, tasn
Subscribers: stefan_schmidt
Differential Revision: https://phab.enlightenment.org/D2604
Summary:
Using using emile to calculate image sha1 instead of md5 to compare
two images, hence making exactness independant of md5.
Signed-off-by: kabeer khan <kabeer.khan@samsung.com>
Reviewers: cedric, tasn
Differential Revision: https://phab.enlightenment.org/D2569
Daniel Zaoui
Daniel Hirt
Stefan Schmidt
Daniel Zaoui
kabeer khan
Stefan Schmidt
Tom Hacohen
Daniel Willmann