@brokenshakles could you please test the revision @bu5hm4n did here to fix the issue?

@Hermet just commited this to disable high quality textture mapping for 1.23 and get problems sorted out after the release.
https://git.enlightenment.org/core/efl.git/commit?id=37870505157d252c057de3910e854ac5650865d6

Thank you, I think you are right.

There is no point in this beeing a Showstopper.

Generally speaking, there was some decision made for the new theme naming style to remove the old-style "include part types in the part names" namespacing. I think this is fine, since we can provide explicit documentation which makes it clear what types each part should be.

For the record: I have a svg icon theme.

I think this is fixed by the svg fix you provided. I cannot reproduce this anymore.

As there is no release today we can see if we can get this in before the release to avoid a known problem which we need to backport the fix for.

I think @zmike should comment on that, i am not too deep into this topic to comment on that ...

@bu5hm4n
Thank you for your opinion. I agree with you.
Then the following cases should be modified to keep consistency with other part names.
"efl.text.title", "efl.rect.background", "efl.text.status", "efl.swallow.event", "efl.content.hotspot", "efl.spacer.opaque", "efl.spacer.content"

I think using namespaces here is not really usefull, with the output of edje-spec in the top of each .edc file, the type of each part is standardized (bc855ec8b62e989d778e47262c7b15e02e70b352). Additionally, from the c api, you see the type per API

What do you think about using edc part type as a namespace?
i.e. "efl.text.title", "efl.rect.background", "efl.text.status", "efl.swallow.event", "efl.content.hotspot", "efl.spacer.opaque", "efl.spacer.content"

I think I did implement it and @lauromoura improved the error message.

are we have any stuff regarding this?
are we need efl-1.23 tagging still in here?

I think we should keep this task for tracking mvvm related work after 1.23 released, so remove 1.23 tag as I see we finished all 1.23 related task on this.

It seems done by D10173 D10181

I think this task is closed by D10035

I think this task is closed by D10171

keep @beta in this released version same as T7871.

it is beta for this release version same as T7871
the mode itself is stable but it must comes with multi_selectable.

reopen task as we decide to mark it beta in this release version.

after discussion on D10184 we decide to mark multi_selectable and multi_selectable_async as @beta for this release.

Okay i am adding c_prefix: efl_ui_selectable; to single_selectable and Multi_Selectable. Revision will come in a few.

actually I think it would better to both of single_selectable and multi_selectable have common API,
like "efl_ui_selectable". is it strange? if it is strange then.. just make them be their own name is okay.

Lets just keep beta for now, we still can remove it later on :)

Okay, how about removing the c_prefix of Efl.Ui.Multi_Selectable, and just fix the API calls ? (I can do that later on)

sorry for spping :p
okay than... stay current name I'll drop the patch
now only matter we take care is prefixes.

Okay we are spinning here in cycles. We cannot use item in the name, since selectable also applies to radio, which is not an item. In the same way we have said above that selection does not work because it's the same as we used with text.

Hmm,, I think Table_Static can be replaced with RelativeLayout. for example,
[TableStatic]

efl_pack_table(table_static, btn1,  0,  0, 50, 50);
efl_pack_table(table_static, btn2,  50,  50, 100, 100);

[RelativeLayout]

efl_ui_relative_layout_relation_right_set(relative_layout, btn1, relative_layout, 0.5);
efl_ui_relative_layout_relation_bottom_set(relative_layout, btn1, relative_layout, 0.5);

if we go
clickable
&
item_clickable,