Update removing the comment. Somehow I forgot it when splitting the patches.

I've rebased the current new API work on top of yesterday (Oct 3rd) master (still in devs/lauromoura/csharp-new-classes) and it compiled without requiring any changes to the Eo files. All tests pass and a quick test showed at least elm examples are working. The generator new code requires some cleanup before pushing, though.

Update with SetIcon change from D7133

Will merge this change into D134, as it already fixes the example build system.

About hiding them from the tree, these are the methods either returning (->) or receiving as a parameter (between ()) a Mixin type.

The Mono compiler already extracts the documentation from the generated code (eolian_mono adds them as C# comments) into a XML file that VS/MonoDevelop use. Maybe we could just add a script to transform the generated XML into the DokuWiki syntax.

I've pushed the current code to devs/lauromoura/csharp-new-classes.

In T7204#124204, @Jaehyun_Cho wrote:

@lauromoura

Thank you for explanation about how to build with meson.

I built with meson and then all elementary functions are successfully loaded by dlsym in class_initializer.
But I still don't know why those functions are not loaded by dlsym with dotnet build...
Our goal is to build EFL C# on Visual Studio so it still matters..

Please let me know if you build successfully with dotnet build.

This @ctor_param would behave just like a hint, right? So each language decides whether it should support them as explicit constructor parameters (C#) or keep it implicit through efl_added (C/C++).

In T7375#124501, @segfaultxavi wrote:

There's an option we have been discussing on IRC. Currently the EO format has a constructors { } section which is unused, and it is not clear what its purpose is.

Marked as resolved. Somehow phab didn't close it after pushing.

In T7240#124187, @segfaultxavi wrote:

@lauromoura with that pyolian magic, can you list all classes inheriting from more than one class (not interface or mixin) ? In this way we can start evaluating how much work would require fixing that.

In T7204#124135, @Jaehyun_Cho wrote:

@lauromoura

It is strange.. I called efl.All.Init(efl.Components.Ui); when I tested. And it did not work on the latest master branch.

I think maybe you tested on your local branch.

Please let me know your test branch or please test on the latest master branch. (if you test on master branch, then please do not use previously installed so files and header files from your local branch.)

Thank you :)

With help of pyolian, I could find these instances where we have abstract classes inheriting from regular classes somewhere in their inheritance chain:

(Somehow I removed myself as the assignee...)

The problem seems to be eina.Value using malloc/free internally to create/delete Eina_Values while it should use eina_value_new/eina_value_free to alloc/free from the Value mempool.

In T7204#124093, @Jaehyun_Cho wrote:

@lauromoura @felipealmeida

Thank you for sharing and fix D6956.

Regarding D6956, still override FinalizeAdd() is not called. (I tested dotnet run with user-defined class which inherits from efl.ui.ButtonInherit.)

The reason is because class_initializer of inherit class in cs file fails to load some efl functions from dlsym (i.e. descs[].api_func) (e.g. efl_selection_set).
This fails _eo_class_funcs_set in eo.c with error message "Class '%s': NULL API not allowed (NULL->%p '%s').".
The efl functions which cannot be loaded from dlsym are methods of mixin, class, and abstract class in elementary. (e.g. efl_selection_set)

My user-defined class is instantiated after efl.ui.Config.Init() is called, so I think that there should not be any problem to load elementary functions from dlsym in efl_ui_button.eo.cs file.
If you know anything about this problem, please share with us.

Thank you :)

In T7204#123998, @Jaehyun_Cho wrote:

@lauromoura @felipealmeida

Could you tell me what branch do you use for the latest development of C# bindings?

Another alternative would be hiding the init into the constructors/class methods, initializing the libraries lazily, at the cost of a bool check on each call for these functions.

In T7204#123722, @bu5hm4n wrote:

@lauromoura Why are there init / shutdown functions at all? Isn't there a way to automatically init elementary when mono is spinning up ?

In T7204#123721, @segfaultxavi wrote:

OK, understood, thanks.

I also understand now the need for the efl.All and efl.ui.Config artificial classes. However, since they serve the same purpose (C# does not support global methods), I really think they should have the same name. As you say, Config is already an Eo interface, so what about efl.Global and efl.ui.Global ?

In T7204#123719, @segfaultxavi wrote:

Thanks a lot Lauro for the very detailed answer. I still have some questions though.

• Regarding class instantiation, I wanted to clarify the type of the variable (unfortunately you used var in your example). So, is the following code still the recommended way? efl.ui.IBox box = new efl.ui.Box(win);

In T7204#123710, @segfaultxavi wrote:

Hi @felipealmeida!

Any progress on this? I am unsure if you need anything from us or you are making progress on your own.

Update with more descriptive message

More info: This happens as the C# wrappers are kept alive by the GC and actually deleted only after the call to efl.All.Shutdown().

Could you check my branch devs/lauromoura/fix-csharp-life on the examples repo?

Do you mean generated classes? The "concrete" ones are indeed sealed as they shouldn't be inherited from. For this use the classes with the Inherit suffix (e.g. efl.ui.ButtonInherit).

Looks like we found where the value changes:

More info:

Just a clarification: The aforementioned commit does not actually introduce this bug, only reveals it through the efl.Loop_Timer instantiation. This may happen to other native calls from the binding.

Mixed up revisions?

Worked fine here, both with and without realpath.

In D6286#110152, @vtorri wrote:

i use d-bus from win-builds

do you know how your d-bus has been compiled ?

Removed the call to dbus-session and it didn't seem to affect anything other than the kill errors.

From https://cgit.freedesktop.org/dbus/dbus/tree/tools/dbus-launch-win.c

In D6286#109365, @zmike wrote:

@lauromoura I will wait on your review before taking further action with this patch since you were looking into this for some time.

In D6351#108855, @lauromoura wrote:

In D6351#108770, @lauromoura wrote:

In D6351#108763, @zmike wrote:

Seems good.

Also those tests should all use EFL_START_TEST and EFL_END_TEST macros if they compile in C++ in order to provide profiling info.

Ok, I'll update.

Actually, all cxx tests are still using START_TEST. I think changing it would be better in another commit, along with the other tests.

In D6351#108770, @lauromoura wrote:

In D6351#108763, @zmike wrote:

Seems good.

Also those tests should all use EFL_START_TEST and EFL_END_TEST macros if they compile in C++ in order to provide profiling info.

Ok, I'll update.

In D6351#108763, @zmike wrote:

Seems good.

Also those tests should all use EFL_START_TEST and EFL_END_TEST macros if they compile in C++ in order to provide profiling info.

In D6286#107645, @vtorri wrote:

./dbus-session.sh: ligne 7: -- : commande introuvable
kill : utilisation :kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... ou kill -l [sigspec]
FAIL tests/evil/evil_suite.exe (exit status: 127)

with dbus-session.sh being the script given by lauromoura

It seems dbus-launch invocation is different from dbus-run-session and can't be used as a drop-in replacement. dbus-launch will start a new bus session and give the code to set the DBUS_SESSION_* variables to this new bus, while 'dbus-run-sesssion' takes a command and runs it on a new shell.

In D6263#107161, @zmike wrote:

I recall having an issue like this too recently when I was doing some Windows work; is this a PATH problem or ?

Disabling this seems bad since it will cause all eldbus tests to fail...

In D6157#104813, @segfaultxavi wrote:

• The structs removed in eina_common.cs and workaround.cs seem cleanup work unrelated to this commit. Maybe they deserve a separate commit?

This seems to have been fixed with ec59f8053a9a7ee7ff848a1bab1d0d980d914bc3, right?

Update after Vitor explained better how these traits should behave.