Instead of
var bg = efl.ui.Background.static_cast(myobj.Part("background"));
Now do
var bg = myobj.Background;
Also a couple helper functions were added.
Now the generated DllImport call will have the actual library name
instead of placeholders on Linux. Before we relied on dlsym being able
to search for the symbols on all loaded so's while Windows needed you to
specify the correct library to call GetProcAddress.
This fixes the case when someone call an function from an efl interface
defined in efl.so (e.g. efl_part) and the library is not loaded yet.
Apparently when we initiate a client side move in ecore_wl2 we flag that
and send a mouse-up immediately on the next pointer enter.
Do the same for resize.
At some point this might need to be revisited, we should probably be
sending a "cancel" at the start of client initiated move/resize instead
of an up at the end?
Fix T6422
Unlike panic, this will be used to handle regular errors
such as parse errors. There will be no jumps and you
will be able to pass in a pointer to get the error
data into some local memory. That way you will be
able to override printing error messages.
In general, ptr(struct) parameters behavior depends whether the
parameter has the @owned modifier or not.
If there is no @owned parameter (meaning no transfer of ownership
happens) and it is a "complex" struct, with reference type fields
(like strings), the struct is converted to the respective
<Struct>Internal struct and passed with "ref" to the DllImport'd
function. For @in parameters, after the function it returns, this
intermediate struct is converted to the public struct type and
assigned to the original parameter, updating it to the external
world.
When we have ownership transfers, the structure is copied to unmanaged
memory and given to the callee. We can't send managed memory directly as
the callee may try to free it. On the managed side, the original struct
is left to be garbage collected normally.
When transferring the ownership of a ptr(struct) from Unamanaged to
managed, we should marshal the reference-typed fields or they can point
to Managed memory that would make no sense to access from C (for
example, strings would return garbage).
The downside is that it can cause potential leaks if the receiver of the
memory do not free it. In the current state of the EFL api this can
happen in two places:
- Efl.Ui.List.SegArray::remove
return -> ptr(Efl.Ui.List.LayoutItem) @owned
- Efl.Ui.Focus.Manager::fetch
return -> ptr(Efl.Ui.Focus.Relations) @owned
The resources copied by both structs may leak when those functions are
overriden in C# and the values returned to the C code.
Also hide some internal stuff instead of exporting it and generate
implicit conversion operators for struct external/internal.
Summary:
This will avoid infinite loops and errors when the parent tries
to orphan an invalidated child.
Fixes T6780
Test Plan: Run `make check`
Reviewers: cedric
Maniphest Tasks: T6780
Differential Revision: https://phab.enlightenment.org/D5839
Reviewed-by: Cedric BAIL <cedric@osg.samsung.com>
Cedric BAIL
Lauro Moura
Derek Foreman
Daniel Kolesa
Woochan Lee
Carsten Haitzler
Davide Andreoli