From C# guidelines in https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members#names-of-events:

Here is a list of generated events from the C# files. (without the prefix).

This is fixed from Harfbuzz Side.
https://github.com/harfbuzz/harfbuzz/issues/1910

In D9674#179781, @cedric wrote:

I actually think that this is an ok usage of key/data API. The call has to stay private. So implementing it as a constructor property require the addition of a private .h function and all the custom thingy to be done manually. A lot more code for something that two line of code solve here. As I am against writing unnecessary line as they bring more problem in the future usually, let's just go with a simple solution aka key/data.

I actually think that this is an ok usage of key/data API. The call has to stay private. So implementing it as a constructor property require the addition of a private .h function and all the custom thingy to be done manually. A lot more code for something that two line of code solve here. As I am against writing unnecessary line as they bring more problem in the future usually, let's just go with a simple solution aka key/data.

yes.

cool.

Okay - then i do not see a reason for this patch...

In D9678#179742, @bu5hm4n wrote:

For the record, i am talking of:

static void
_anchor_del_cb(void *data, const Efl_Event *ev EINA_UNUSED)
{
   efl_ui_popup_anchor_set(data, NULL);
}

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.

Okay.

For the record, i am talking of:

static void
_anchor_del_cb(void *data, const Efl_Event *ev EINA_UNUSED)
{
   efl_ui_popup_anchor_set(data, NULL);
}

But it seems that the deletion of the anchor is different to what is happening if you are unsetting it (or i am just not seeing the equalness), anyways:
_anchor_calc already gets the private data of the widget, also getting the pd of the popup is not that much more.

We may encounter some difficulty generating the files in sub folders as a meson issue [1] limits the output of custom_target command to be placed in the same folder as it is called.

So you want to have efl.ui.widget.scrollable_content with a scroller_style property?

How would your proposed change handle _anchor_calc without performing another eoid lookup?

You are right the documentation and the code do not agree on this. I have no strong feeling on how to fix it and will accept a patch that goes one way or the other. Maybe @segfaultxavi has an idea.

I think @bu5hm4n will not be happy with this patch. Is @bu5hm4n the object cop?

Maybe later.

Nice! can you add it to the spec unit test ?

I think the move to the callback array does make a lot of sense, but the usage of a object pointer in the private data is not a good idea, we should get rid of that. in the invalidate case you could also just use the same API again to set the anchor to NULL (which would also garantee that we have additional cleanup operations) in one place, and so reduce code dups.

rebase

rebase

<3

rebase

rebase

rebase

rebase and avoid using key/data API to please @bu5hm4n :-)

rebase

Looks great otherwise :)

In T8151#140567, @ali.alzyod wrote:

This is clear things up, to know that we are based on current existing stuff

So how about break this @property font
Into :
@property fontfamily
@property fontSize
To make it more clear what does it mean.

https://i.redd.it/i8933fmx30l11.png

This looks like it's removing docs, summoning doc cop...

In T8151#140553, @ali.alzyod wrote:

@tasn
Again Font should not be interface, Are there font-able objects other than font object?
If my class use font object then he composite inside, not adopt new interface, do you have any example from other platforms ?

Even though I sat on this for a few days before posting it here, I'm now not sure if we want to encourage this "out of eo" behaviour. So I'm closing it for now, but at least we have it for posterity.