In D11215#220003, @zmike wrote:

But if you're setting repeat here then that means the button will get the event as well as the object below it inside the parent smart object?

In D11215#219874, @zmike wrote:

Sorry for the delay.

Can you elaborate on the case where this is needed? Conceptually, it seems like if I click a button in an entry then only the button should be getting the event?

Rebased

Fix review comments.

Actually I followed the old convention, its been little while since I had not contributed.

• Revert "[elm] Add missing sizing eval hook at radio"

In D9378#173463, @bu5hm4n wrote:

Can you remove it again from radio then ? (63275dfef864282170e0c30d765eddf3ee41cd27)

It seems unnecessary to have it in both.

• example edc added to build list

example updated

Fix typo

In D9053#167470, @ali.alzyod wrote:

In D9053#167456, @subodh6129 wrote:

@ali.alzyod
Small query here,
why do you need separate caching logic for variation sequence? Can't it be accommodated in the current logic?

-because variation sequences can vary from ( 0xFE00-0xFE0F , 0xE0100-0xE01EF, 0x180B-0x180D), So I think create hashing tables for these values for each character (or characters that could have variation sequences) will consume more memory, and logic will become more complicated where one Unicode value could have many variation sequences.

-So I thought of binary search as good solution where we will keep old logic as it is, and if character has variation sequence it will be added to variation sequence sorted list, and accessing will be fast specially list will be small for each unicode value.

@ali.alzyod
Small query here,
why do you need separate caching logic for variation sequence? Can't it be accommodated in the current logic?

@herdsman are you there?

Well I tested this in Tizen platform and so far there is no issue reported, if you have any abnormal behavior after applying this patch,
Please let me know. Also I am curious about the FIXME comment.

please close if its done

?

There is way to do that in textblock.

You can see if we use fit option in textblock part, after whole calculation of edje part objects
we do a special calculation for textblock if it has fit option enabled. This will indeed calculate the textblock size again.
Please check the functions

_edje_part_recalc and _edje_textblock_recalc_apply.

It will improve performance of fit calculation and moreover
textblock calculation is being done twice.

Steps to check:

1. Apply the attach patch
   fit_option_issue.patch2 KBDownload
2. Remove function

_edje_textblock_recalc_apply

3. Launch elementary_text
4. Search for genlist->Genlist Group
5. Resize the window to accommodate whole group index text. (Make it bigger)
6. Click button "Bring top 477"
7. Resize the window to so that fit can be applied (make it smaller)
8. Click on "Show 0" button

Check this image{F3048970}

Removed duplicate patch

Useless

Splitted

Spilitted

When we run some static analysis tools, they think after return no statements execute which is true but in this case this is just to avoid compiler warning for unused variable. So I made this patch, although not really required.
One more opinion of yours will let this fly off.

Fixed more issue.

Even if the value of

attr_orig_amount
``` and

attr_size_amount

are changed, I am not sure how these will affect the value of

attr_amount

Update accordingly