The interface name was added to the struct name in order to avoid collisions between event arg structures with the same name. Removing this prefix leads at least to the following clashes:
Thu, Aug 22
Wed, Aug 21
Here is a list of generated events from the C# files. (without the prefix).
We could try hiding them but AFAIR they should be public so inherited classes can use them.
Evt today comes from the name of the event. Related to T8163
This could be kinda tricky to do in a generic way. We may end up having to build a list of irregular verbs and their past tense in order to generate them.
We may encounter some difficulty generating the files in sub folders as a meson issue  limits the output of custom_target command to be placed in the same folder as it is called.
Jul 24 2019
Good news! DocFX already filters out methods with the [EditorBrowsable(EditorBrowsableState.Never)] attribute :)
Yeah, looks good to me. Add this attribute to all classes and methods you think should be hidden from the standard C# user, and I'll also blacklist them from DocFX.
Jul 23 2019
Maybe we could use something like this EditorBrowseableAttribute, so IntelliSense and friends ignore them.
Apr 10 2019
Apr 5 2019
Apr 4 2019
Apr 3 2019
Apr 2 2019
This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.
Mar 26 2019
Mar 22 2019
Mar 21 2019
Mar 19 2019
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.
Mar 18 2019
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?
Feb 14 2019
Feb 5 2019
Jan 28 2019
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.