| cedric | |
| bu5hm4n | |
| zmike |
efl_del should be used only when an object has a parent.
The previous code leads to efl_del error messages in C# due to being
called on objects already without a parent. We can't guarantee the order
the objects in C# are collected, even if they have a parent-child like
relationship.
Fixes T8216
| No Linters Available |
| No Unit Test Coverage |
| Buildable 13196 | |
| Build 9364: arc lint + arc unit |
I recall adding something like this previously and then @cedric said to do something else instead
I recall the same, but we still have this issue, and i think we really should do something like this, the logs of our test suite is full of this.
It is my understanding that Evas is always in the parent chain and has ownership. So it should always be able to do an efl_del. If it can not, it should be reported as an error and we should investigate why it is happening.
One of the case I have noticed that we do not handle well at all is when there is a reference outside of Evas on a child. We should properly disconnect the Evas object and not reference the canvas anymore on efl_del even when there is still reference hold on the object, but this is a different behavior than legacy as legacy would just blast any reference still owned. What a mess. Oh and there is also the del, but not completely del yet state. Anyway.
In bindings it can happen that a object has a ref while it gets efl_del'ed. Which will leave it unparented. Additionally, you can create Efl.Ui.Win with efl_new so i think this is required.
Isn't the issue that we shouldn't force destroy object in Evas on canvas shutdown actually?