This code reproduces part of the problem.
This causes build error with --enable-csharp-bindings.
Because Efl.Canvas.Gesture becomes Efl.Gesture and we already have Efl.Gesture.Events.
Efl.Gesture was a namespace in C# but now it becomes a class as well.
The problem appeared by switching to EFL-121.1 and E22.
When I go down in version it disappears.
I did not find how to reproduce it, I did not find any factor causing the problem.
I do not understand the opening of this loop, since it was only at the opening of the apps that I found it.
How about separating Efl.Ui.Stack features from Efl.Ui.Active_View.Container?
The documentation changes will be addresses when Xavi goes over the docs and polishes them (happens bebfore this lands.)
I see. As you said, you do not need to fix typo in documentation now but it would be greateful if you comment on documentation which I feel difficult to understand. (e.g. bind)
It would help me to understand better how methods and codes work :)
Rebase and rename.
Rebase, rename and improve doc.
We've tried measuring the eo benchmarks for it using the release build on an dell xps 15 9560 running ubuntu 18.10.
Sounds better to me.
Could be. The alternative is checking pd->adapter on line 71.
Mhm, i have the strong feeling that this is wrong, even if something does not need the adapter, an item can be realized again, which would require that the setup order function is called again. Which seems not to be the case after this patch ...
What are the result benchmarking this?
Doesn't that have an impact during initialization? Wouldn't that prevent a sizing eval during finalize?
benchmarks and some updates
It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/
the fuck is a draft revision