@jpeg

Hmm. I don't get it. What's going on there? MY_CLASS_NAME_LEGACY is correctly defined as "elm_button" (and not "Elm_Button" anyway).

The "elm_button" is supa dupa legacy. It is older than "Elm_Button".
The "Elm_Button" was appeaed and it was returned from "elm_object_widget_type_get()". The "elm_button" became leagacy and it was returned from evas_object_type_get().

Now, "Efl.Ui.Button" is appeared. So, "Elm_Button" and "elm_button" have to be legacy.
If the object is added from "elm_button_add()", it has to show legacy name just like before.
Efl.Ui.Button_Legacy is totally new name. Not Legacy.

How did you get the wrong type name???

Try elm_object_widget_type_get() function. It will return object's given class name.

This change should either be done on ALL legacy widgets or there is some logic error somewhere which needs to be fixed. One way or another, this change is dubious.

Yes, I prepared patch for asking the way to resolve the issue.
If reviewers accept this solution, I can update it as big one patch or create multiple patches for each widget.

In D5782#98913, @id213sin wrote:

@jpeg

Hmm. I don't get it. What's going on there? MY_CLASS_NAME_LEGACY is correctly defined as "elm_button" (and not "Elm_Button" anyway).

The "elm_button" is supa dupa legacy. It is older than "Elm_Button".
The "Elm_Button" was appeaed and it was returned from "elm_object_widget_type_get()". The "elm_button" became leagacy and it was returned from evas_object_type_get().

Now, "Efl.Ui.Button" is appeared. So, "Elm_Button" and "elm_button" have to be legacy.
If the object is added from "elm_button_add()", it has to show legacy name just like before.
Efl.Ui.Button_Legacy is totally new name. Not Legacy.

How did you get the wrong type name???

Try elm_object_widget_type_get() function. It will return object's given class name.

I didn't know that function. F*ck that.

This change should either be done on ALL legacy widgets or there is some logic error somewhere which needs to be fixed. One way or another, this change is dubious.

Yes, I prepared patch for asking the way to resolve the issue.
If reviewers accept this solution, I can update it as big one patch or create multiple patches for each widget.

Then this patch is correct. And thanks to @taxi2se's efforts in the "Legacy" classes we can actually do this. Can you handle the other classes as well? Then I will accept your patch.
Thanks!

Until efl-1.18, eolian replaces namespace separator '.' to '_'.
So the classname would be like

static const Eo_Class_Description _elm_button_class_desc = {
     EO_VERSION,                                            
     "Elm_Button",                                          
     EO_CLASS_TYPE_REGULAR,                                 
     EO_CLASS_DESCRIPTION_OPS(_elm_button_op_desc),         
     NULL,                                                  
     sizeof(Elm_Button_Data),                               
     _elm_button_class_constructor,                         
     NULL                                                   
};

But when eolian_gen upgrades to eolian_gen2 (efl-1.19), this logic seems to be deleted, thus

static const Efl_Class_Description _elm_button_class_desc = {
   EO_VERSION,
   "Elm.Button",
   EFL_CLASS_TYPE_REGULAR,
   sizeof(Elm_Button_Data),
   _elm_button_class_initializer,
   _elm_button_class_constructor,
   NULL
};

So we have 2 legacy class names: "Elm_Button" and "Elm.Button"

@taxi2se
Thank you for comment.
I think we can ignore "Elm.XXX" legacy type name if it was merged to EFL recently.
Then, this patch will be acceptable.

almost done... just "which efl version is this for" is missing (see above review requests) :)

In D5782#99070, @raster wrote:

almost done... just "which efl version is this for" is missing (see above review requests) :)

In fact, see T5938, we may want to add this new startup API for "which version of EFL was this app written for?" (not compiled with, but QA'ed with). We could then switch the name based on that rather than elm_button_add vs. efl_add (note: the name has changed multiple times so there is no actual fixed value here... this compatibility patch therefore is imperfect)

@raster, @jpeg
Thank you. I forgot to add comment for EFL version. :)
I'll update it soon.

Anyway, I added a comment for EFL version information based on my poor English writing.