Using the language mechanisms for casting (obj as Efl.Ui.Button) sounds better than having a custom method, from an API point of view. I do not know how hard that is, though.

In order to integrate better with the C# ecosystem, we have do adapt. This should not be a big change in current C# code, as we moved on from that old all-interface API scheme.

What? Are we going to change the API now?

This is done and committed in the www-content repo.

This implies PascalCase namespaces, proper event names, no more interface classes and no more initialization methods.

The EFL_MAIN approach is very nice for the tutorials because it allows for very compact examples, however, I am afraid it looks "intrusive" to bigger projects. If EFL is only a small portion of my whole program, why should I give it control over my Main()?
I prefer the "Only use EFL calls between efl_init() and efl_shutdown()" approach. I think it is common enough that all users will understand it.

Well, i think documenting that only calls to efl classes are only allowed from beeing inside a efl-callback is pretty much sane, as its just like *Only do efl class calls when you are between init / shutdown*. With the difference that this code requires far lesser boilerplate code. Constructor parameters still can be passed and added from the user as he likes.

The problem with letting the user execute things before is that they may try to instantiate EFL classes that haven't been initialized yet. Constructors parameters could be passed as "varargs", unfortunately in C# they are the same type (like an array) IIRC, which would not work.

We can predefine a main method in C# however, how do we receive the class that is implementing the Application Interface ?
The Application also could be a abstract that already defines a launch method that cannot be overridden, so the code would look like:

If people have to write "public static void Main()", will they really use the Launcher?

Sure, I like it. What do the C# experts think?

Neat !

@cedric See my comment https://phab.enlightenment.org/T7204#127190 . There is a POC which implements exactly this behavior :)

Also for reference in C, EFL_MAIN expose the Efl.App object directly as parameters in main. I do not know how the initialization of the C# binding is being done actually, but maybe something to investigate. Would be best if EFL_MAIN_EX behavior was also available. I will do the review of the patch right away.

@cedric well the efl.app is just inheriting efl.loop so getting Efl.App instead of Efl.Loop is not really a difference, are you fine with the patch above ? This would solve this and allow bindings to use the Efl.App object.

Hum, if you are getting the main loop object, you should be able to do an efl_loop_provider_find on it to get the application. As for returning an Efl.App instead, I guess it would work the same as you can always do a provider_find. So I think it is fine to provide the Efl.App instead. Might make more sense.