Fix several integer binding type deduction based in its size on C.
Generation for function pointers no longer use modified argument name
which is different from the parameter name.
New generation context for structs.
bool from UnmanagedType.I1 to UnmanagedType.U1 (correct use
inside structs according to mono documentation).
byte (signed char) and int8 now is correctly represented by
sbyte in C#.
Check parameter direction in some out generators in parameter.hh.
Add efl_libs.csv to gitignore.
Make eina.Value pointer constructor public.
Add missing fields to efl.kw_event.Description struct.
Remove eina.File workaround (let struct gen handle it).
Remove is_function_ptr bool from regular_type_def and
add a typedecl_type enum to it. Also add some helper
methods for easier comparison.
Left some test cases commented for when pointer parameters
are properly working.
in some cases construction can fail badly and this causes a crash...
eoid is NULL going in and this causes a cascade of failure. survive
and be more robust.
we really should have data inside the loop object, so begin moving it
one small thing at a time. this is the basics that will allow multiple
efl loops. make an eo efl object and class for fd handlers that is efl loop
bound make fd handlers really bound to their parent loop and not global as
well as have a nice class/obj. create an message queue per loop and
put legacy ecore events on top of it... and a lot more.
this is not 100% done, but it's a lot of the core and groundwork.
various ecore_timer_add(), ecore_diler_add() etc. need changes.
The following still need doing:
ecore_timer (internal usage for sure)
ecore_idler (internal usage for sure)
ecore_idle_enterer
ecore_idle_exiter
ecore_pollers? (is the new efl loop stuff ok?)
ecore_exe (fork/spawn from any thread and track exe from that thread?)
ecore_signal code
ecore_throttle (should we have a single global too? we have per loop)
ecore_app ? (should every loop be given its own argv/argc?)
Lots of internal ecore code uses/calls these legacy calls and we
should have efl loop replacements and/or use the ones we have
The following will bedifferently designed for loop to loop
control/messaging/ipc:
ecore_thread
ecore_pipe
Summary:
Size and align calculation in Efl.Ui.Popup was advanced using group calculate,
so Efl.Ui.Popup.Anchor apply it also.
Test Plan: elementary_test -to efl.ui.popup.anchor
Reviewers: Jaehyun_Cho, herb, jpeg, woohyun, cedric
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5655
Efl_Ui_List doesn't properly define, as it should, the class Efl_Ui_List_SegArray. This workaround allows the mono binding compilation in spite of this.
yet again a fix needed for something that should have been tested
BEFORE a push. build stuff AGAINST efl. seriously. do you forget to
put your pants on before you leave your home? is it that hard to do
something as simple as BUILD AGAINST EFL before a push if any commit
you did made changes that MIGHT affect that? serousoly? do i have to
remind peolpe to put their pants on? i already have done this several
times recently. thigns that would have been caught by simply building
against efl after changes and before a push. this is a basic thing to
do like putting your pants on. do it.
As we do not ever use the udev_devices created from
udev_device_new_from_syspath in these functions, remove them.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we cannot create a new udev device, then we should free the
previously created udev enumeration from above.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Daniel Kolesa
Andy Williams
Carsten Haitzler
Vitor Sousa
Cedric BAIL
Marcel Hollerbach
Jean-Philippe Andre
JinYong Park
Felipe Magno de Almeida
Chris Michael