@Hermet my take on this is that line 175-178 should be removed and replaced with a DBG, and the content (seldata->content.mem) should NEVER ever be printed. It could contain a image or binary data just indicated with a mimetype in the beginning - that is nothing we want to print out on the terminal. (It could contain escape codes or things like this, which could lead to weird behaviour in a terminal emulator.)

@Hermet all this is debugging output, this should actually never been in the function IMO. And errors in return values don't matter at all there. But those are just my two cents :)

eolian_gen is just the binary variable that is used to call eolian_gen in the build process.

The approach yes. However your goal can be achived a lot easier :)

I never really tried it myself, but its probebly enough to have something like

[binaries]
eolian_gen = ['path-to-eolian-gen']

In the cross file.
(http://mesonbuild.com/Cross-compilation.html#defining-the-environment)

Looks good to me.
Is the struct in our API or not ?

... This ... breaks ... eolian_suite ... even CI reported it!

Yes this is not done yet. I just landed the first bunch so it is ready for more, this is deinfintly something that needs to be done - however, i don't have time yet.

Okay - but if you aren't happy with the current situation, then things are likely to be changed anyways. With this we have a solution for the constructor things for now. If things change this will get reimplemented in a different way. But in the meantime we have a solution ... :)

funfact of the day:

In T7366#125149, @Jaehyun_Cho wrote:

@segfaultxavi @bu5hm4n
Thank you for your explanation. It helps my understanding about Eolian clearly.

@segfaultxavi

2. Mixins
   1. Mixins inherit from their primary ancestor, which must be another mixin or an interface.

Do you mean abstract class as an interface? (i.e. mixin can inherit from abstract class as primary ancestor)

That is correct thx! :)

Mhmm this appears to not be usefull :(

THX :) will Land soon, I am not at a laptop right now.

In T7366#125092, @segfaultxavi wrote:

In T7366#125085, @felipealmeida wrote:

I'm not sure removing Mixin from inheritance tree helps in anyway.

Let's say we create class A (everything in Eolian) and it inherits from Mixin M and regular class B.

Now, Mixin M inherits from regular class C too. If we remove Mixin, we still need to inherit
form both B and C in A, which is still a multi-inheritance problem.

Regards,

Indeed, the diamond problem is already in our hierarchy, no matter how we implement it in C# (look at the picture linked above).

I think mixins have been abused inadvertently: There are 40 EFL mixins (I am not counting legacy), of which, at least:

• 6 inherit from Efl.Object
• 3 inherit from Efl.Ui.Widget (OMG! look at the diagram for efl_ui_view_list.eo)
  
  All these have to be fixed. Remember that this task is about "Evaluate work needed to fix EO classes inheriting from more than one regular class or abstract", so the parent task can continue ("Not allow multi class inheritance in eo").

I actaully don't know right now what this is abount resolving what exactly ?

I will check it once i am back at home on the mac and then merge it :)

Okay, now i understand what you are doing :)

Uuuuhm, how can strlen return a same value of the string does not terminate with /0? O.o

...

...

...

the focus, unfocus legacy events are a bit weird, focus or unfocus usally means that this element has focus, this is the entry point where key events are emitted. However, this is not the case for composition. The focus is on one of the internal elements of the widget, not the composition widget.

In case cd->stack is NULL then top_cd can be NULL I guess ... :) @YOhoho

....

Its not perfect yes, but its the meson default, i don't like to change that :)

Seems to be resolved. Cannot be reproduced anymore

Ignore my comment :)

Wait,

@ManMower it's not really about beeing lazy and not fixing all the cases, it just does not make sense. Where is the difference of you knowing that the callback is already dead, because it was already removed, the object beeing dead, so the callback is never called, or the callback is dead, because it was never registered? Its not that there is some heavy sideeffect if you call callback_del_* twice or so.

No, I am talking about using "eina_vpath_resolve_snprintf" in line 21, so no free() is required :)

This Option only works for Android afair :)

Maybe its better to use the vpath resolve variante which takes a static buffer, instead of the allocated string :)

To me this looks like a problem with the get text call :)

Okay, this is accepted but not landed. I am just yolo'ing it in. On @ManMowers resposibility :)