we did a completly wrong thing here, and it only worked by accident.
We passed a absolut path into a parameter where only a number should be
passed. This is now fixed.
This fixes meson build with meson-0.50 and bindings enabled
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8328
Summary:
This commits adds dotnet as a supported C# platform for EFL# bindings.
Due to differences between Mono and Dotnet regarding DllImport, the
bindings now are using an imperative approach to load the function
pointers through the NativeModule and FunctionWrapper classes. These
classes handle the dlopen/LoadLibrary and dlsym/GetProcAddress calls.
Also, the previous caching of non-owned strings returned to native code
was removed until further memory checks.
We also had to create workaround for bool and chars in Structs for C#
marshaling. Going through System.Byte instead and Marshaling manually
to their respective types.
In order to actually build efl_mono.dll with dotnet right now,
issue #4782 from Meson should be fixed to make it properly detect and
used the Dotnet compiler. Also use "-Ddotnet=true" when running meson.
Fixes T7394
Reviewers: felipealmeida, vitor.sousa, bu5hm4n
Reviewed By: vitor.sousa
Subscribers: cedric
Tags: #efl
Maniphest Tasks: T7394
Differential Revision: https://phab.enlightenment.org/D8069
Summary:
The previous declaration was causing the implicit copy constructor to be
invoked when copying a new eina::value from an existing eina::value,
thus leading to two wrappers pointing to the same underlying C pointer.
This showed some error messages when running the tests but under autotools
it didn't fail, while building with meson caused it to segfault.
Reviewers: vitor.sousa
Reviewed By: vitor.sousa
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7166
Summary:
Also changed the previously failing tests to use ck_assert_int_eqinstead
of fail_if for better reporting.
Test Plan: make check
Reviewers: cedric, felipealmeida
Reviewed By: cedric
Subscribers: #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6194
Reviewed-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Also added a blacklist header to temporarily disable generation of eo
methods with futures as arguments or return type.
Once the models branch lands, we should enable future support again with
eina_futures.
Reviewers: cedric
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D6018
This reverts commit 135154303b.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
like this.
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
then?)
etc.
This API is meant to be used by parts only, and by bindings dealing with
part objects. This patch fixes make check which got broken in the after
the previous one (cxx).
This is really just calling efl_del() and detaching the internal pointer
from the C++ object. This will not affect other references, which means
after del the object may still be alive, probably without a parent.
This prevents generation of del().
I also removed constructor, finalize and destructor as I believe this
requires special work with eo_inherit (where did this work go??).
I'll hide some controversial features behind this, until we come to an
agreement with @felipealmeida and people who actually know C++ (iow: not
just me^^).
Features protected:
- easy wref (using -> without locking)
- xxx_event_cb_add() functions in object classes
- instantiate(obj) to create a new object
- add as a synonym for instantiate (both in efl::eo)
I think some concepts are not handled properly in this set of classes.
I'll do some more experiments to see if I can find a working solution,
but I think we need 3 variants of eina_value, instead of just the two
provided.
This still uses the instantiate object but provides a more convenient
syntax for objects declared before their creation (eg. a global win).
Note: I wonder if we shouldn't rename instantiate to add. It would be
closer to EFL API's while being much much easier to type.
On instantiation objects get either one or two refs:
- with a parent, they will have 2 refs, one for C++, one for the
parent.
- without a parent, they get a single ref, the one for C++
This will break the existing C++ examples, which I will fix in later
patches.
Note that the window is a strange object which can be created with no
parent but internally reparents itself to an object it creates (oh so
ugly).
I hid it behind ifdef for now as I'm very much unsure of what I'm doing.
This whole modern C++ thing is still weird to me :)
Prerequisite:
#define EFL_CXX_WREF_EASY
This allows constructs such as:
auto wobj = obj._get_wref();
std::cout << wobj->text_get() << std::endl;
Marcel Hollerbach
Felipe Magno de Almeida
Lauro Moura
Cedric BAIL
Carsten Haitzler
Jean-Philippe Andre
Andy Williams