It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/

@lauromoura @felipealmeida After the previous revision and this, there are only c calls in the init calls.

I also tried to remove those, however, they are used in the intree examples. Which brought up the questions:

• why we have those intree examples in efl AND additionally out of tree examples in the examples repository?
• What do you think of having something like a Tutorial class, which ensures the correct init calls in the background? In the class in the end only the class calls are there, to me it seems that a user should only use the application internface, but never bother with the subsystems in detail. Which would be ensured with that, is that fine to you ?

@bu5hm4n I do not understand what would the Tutorial class do. Who would use it? Only the tutorials?

In D7556#132772, @segfaultxavi wrote:

@bu5hm4n I do not understand what would the Tutorial class do. Who would use it? Only the tutorials?

Only the tutorials, it is only used to simulate a running EFL application :)

Why wouldn't the tutorials use the same classes as regular EFL apps? I am confused.

After an IRC chat I finally understood it. @bu5hm4n is saying that some of the tutorials (like the Eina ones) do not need to initialize the whole EFL, but they won't be able to initialize Eina alone if Eina.Config.Init() is removed.

I think initializing the whole EFL is not a big deal for these tutorials. They are already using Efl.All.Init() anyway, so let's just turn them into regular EFL apps using the new App interface. I certainly prefer this to creating a Tutorial class which will be more confusing.