A work proposal which has been voted on and accepted
Thu, Feb 14
Tue, Feb 5
Mon, Jan 28
Jan 23 2019
This is done and committed in the www-content repo.
Jan 18 2019
This implies PascalCase namespaces, proper event names, no more interface classes and no more initialization methods.
Jan 16 2019
Dec 20 2018
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?
Dec 19 2018
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.
A more complete example:
I like this idea, it makes sense from the user standpoint. Is there any problem regarding the implementation, @lauromoura ?
I was looking a little bit into this in order to get to efl_config.eo.