No no, you should not, I just wondered if you did before ... (but you you didn't, which is correct).

I did not set the CFLAGS, should I set them?

I am not sure why people are seeing this (you are not the first one), there is not a single call within the efl-build that is loading old e* libraries from the system to compile based on that. And the -I / -L flags are added as first by meson, only the user CFLAGS go higher in the priority, have you set custom CFLAGS that are including the libraries from these directories? (Or is your compiler not honoring the ordering of flags like (for example) mine) ?

if you had the old built tree around a "make uninstall" would do it. but i guess you don't... so yes - you'll have to manually uninstall it. delete all the ecore, edje, evas, etc. etc. dirs and libecore* etc. etc. libs that come from the efl install.

I have installed one of them 1.20.7 to have terminology working months ago, the second installation is the one compiled 1.23.2.

you have a classic "2 installs in 2 places" problem.

I think it doesn't matter for editor that supports autocomplete.

it worked now :S, I am suspicious about the environment variables were causing the issue PKG_CONFIG_PATH, LD_LIBRARY_PATH and CFLAGS,

can you please try a ninja clean before building?

It could be that these classes are currently unused, yes. @cedric should know. @cedric?

@segfaultxavi
I tried to improve descriptions for efl_loop_message_future.eo and efl_loop_message_future_handler.eo.
They look like actually unused, though.
I mean they are created and assigned but there isn't a place that accesses or call some apis to those things.
Am I wrong?

1. target -> "base"
2. Relative_Layout -> "Relative_Container"
3. keep "child" as it is
4. relative -> "relative_position"

I was thinking we cannot do this in c either,
but yes, I forgot the existence of efl_part.

The solution to the last issue is to have something like templates, where we can specify this on a interface.

In T8380#146523, @woohyun wrote:

1. I also like "base" instead of "target"

+1 "base"

2. "Relative_Layout" come from other platforms' class name with the same usage. If, everyone else does not have any bad with "Relative_Container", we can go with that :) (I hope to get more candidates for this class's name)

+1 "Relative_Container"

3. "child" , "key", "value", "current", or "content". I think just keeping consistency with other classes would be good for this value for "keys".

Hmm.. i can't find a better name than "child".

I just spotted that this class return a list<> instead of an iterator. Must be fixed before taking it out of beta.

Efl.Gfx.Align has been landed in D10554 and D10555. I hope everybody is OK with it :)

ping

Given that the values here are effectively "double value which means alignment" I'm wondering if we want to consider an efl.gfx double type for this (e.g., Efl.Gfx.Align) so we can be more explicit; this already has a number of places it can be used...

I agree that we should reserve the term "layout" for things related to layout (edje) in EFL, even though this may be confusing for other platforms.

Thanks for sharing your opinion.