I am not convinced by this change as we loose the ability to set the theme during widget creation.

In the h files and the c files become the x file basically.

The compiler can only inline function in files it sees directly when compiling a unit. That is why wine has so many eina_inline*.x files.

Maybe we might want all this function to be inline, other than that it looks good to me.

I am not convinced of the need for double, otherwise yes.

Please split the patch. One that had eina range and one that use it. Also I am not sure of the type. Unsigned int would seems better for our use case. Also there is no point into adding the type in the name of the data structure.

I am unlikely to have the time to take care of that, but I should be able to review the patch in the next 2 weeks.

Hum, it seems we are getting to a logical point where indeed range is a useful structure to add to Eina.

In D11044#209054, @bu5hm4n wrote:

Note, you can run *all* examples after a refactor with ./examples_checks.py in the root directory.

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase and address comments.

In D11044#209051, @bu5hm4n wrote:

I might be a bit stuborn on this. But isn't array just the same problem as list ? Why not just entering a iterator ?

In D11051#209050, @bu5hm4n wrote:

Mhm the only user of that was clouseau ... But that one does not even compile after renames and eolian changes, what should we do ?

I will work on this this week then.

Can you update the commit message also to remove the last ) that goes automatically in the url?

Some more review.

I am not sure we want this behavior, maybe @woohyun or someone else in Korea would have an opinion on this.

Ping?

rebase

rebase and add a placeholder.

rebase

rebase

rebase

rebase

rebase and add focus to commit message.

rebase and free info.

retrying

retrying

retrying

retrying

rebase and reorder maybe

rebase and reorder maybe.

This was resolved by 115a9a22b1d25d8d3b2d433994cc6756174b11b9

In D11049#208649, @segfaultxavi wrote:

This struct is the only thing in the Efl.Gfx.Event namespace... looks weird.

rebase and address comment.

rebase

rebase

rebase

I am also happy with the plan to add a markup_generator later on to support multiple markup language.

In T7858#149040, @ali.alzyod wrote:

In T7858#149032, @cedric wrote:

In T7858#148994, @ali.alzyod wrote:

@cedric
I am not catching exactly your comments, Are you referring to internal implementation or API exposed to users ?

API exposed to users

Can you please show me what you expect to expose to the user?

As you noted there is a two level type. One is indicating that it is an Eina_Value_Type_Content to Eina_Value and the other one says what is inside the Eina_Slice. This means you have two level of operation and is the current justification for the existence of Eina_Content, but there is nothing that prevent having:

I saw your patch, but I am worried that overtime we are going to add more and more stuff in Eina_Content and it is going to spread and duplicate a lot of the logic that is in Eina_Value and you will have to write the Eina_Value part anyway so that it can be propagated with Eina_Future... The sanity checks can still be there when you instantiate an Eina_Value_Type_Content and any conversion to it, will be sane as it will be done internally by Eina_Value.

In T7858#148994, @ali.alzyod wrote:

@cedric
I am not catching exactly your comments, Are you referring to internal implementation or API exposed to users ?

I am not sure we really need Eina_Content. An addition to Eina_Value to support a tupple {Eina_Slice, IANA types} seems like it would work. Default conversion would be toward UTF-8 for text and there could be an additional API on Eina_Value_Type_Content that would allow the conversion of an Eina_Value to a new Eina_Value_Type_Content of a specific IANA type. With this I would think you have all you need and will have a lot of conversion operation available right away (Plus all existing infrastructure around Eina_Value).

In T7858#148972, @woohyun wrote:

@cedric
Thanks for sharing your idea.
Is it something different from "efl_text_markup_util" class ?

I am not a fan of the current Efl.Text_Markup logic as it is pretty much impossible for the application to leverage it for a custom type. I would really prefer a logic where we can set a class/object that is in charge of interpreting the markup language string and convert it back and forth to native text API when a user call markup set on an object. This way all the markup language of the world can be easily supported and efl doesn't need to do it itself. Currently, it is not the direction we are taking. The reason why having a converter class/object is nicer than to require the creation of complete new class for an application, is that it divide intent clearly and reduce application work needed in just providing that conversion logic.