We found some issues while doing a internal dev-day.
And I got some feedback.
I think some issues must be fixed for stable work.
- The problem of tree depth of generated ML
There is a problem with the generated ML tree.
This is mostly the case when ML is generated.
window - container - content ... - content - container - content ... - content
There is no case where the container is the chlid of another container.
db was built on all ea files.
The Elm.Box in the DB has many container widget in Containers.
However, a box using container will not be created.
This may be a frequency issue. But at least it did not happen in the tests so far.
Eventually, the more the DB, the more overlapping widgets will occur.
I think this must be fixed.
- Too many items
This is probably due to the implementation of test_genlist.
test_genlist creates a very large number of items for stress testing.
ml_gen does not necessarily follow this.
Sometimes, App gen generates a very large number of items and allocates a lot of memory.
I think it needed that the tool user can to adjust the frequency of item creation. or number of item's max occurence need fixed
- Meaningless scenario
If all the shots in the generated scenario are the same, then this scenario is not necessary.
Of course, even if there is no change between shots, the scn can be a test unit.
But I think this is the problem.
If you do not have enough time, we can develop this feature.
If all the shots generated are the same, they can be displayed in name.
Scenario #1 - same
Scenario #2 - diff
- Event play
For example, a button widget, Click event is created in button ML.
This clicked event is called with callback_call via exactness_play.
This is an internal operation only and can not check that the pressed and unpressed edc of the button is well-behaved.
The checkbox is also called "changed" but it does not change checkbox image in player.
Maybe most elementary widgets have this problem.
We need to let the player generate a hardware click event rather than a legacy call.
The commented that in exactness/src/bin/player.c _feed_event의 EXACTNESS_ACTION_EFL_EVENT needs to be reviewed.
(If the event is a problem when the widget overlaps, I think overlaping's a problem.)
What do you think?
There are some other feedbacks when I received dev-day.
Graphics API test support, lottie(vector) animation test support, recorder GUI support, etc.
I think we should review these feedback
Please let me know what your opinion about issues :)