remove an unwanted change from this patch

elementary entry: apply scale to entry_edje when an entry is scrollable

It fixed many issues caused by recent changes in Edje.
I'll accept this patch. Thank you.

add since tag

Remove error/critical messages with/without GL

@cedric
I found you pushed patch to use efl_unref() for removing error messages from efl_del when there is no parent.
But, if you enable GL engine support, fb->buffer will have a parent. So, efl_unref() will print the critical error messages.

Hmm... efl_unref also prints another error messages. I think it is not the perfect solution for the issue.

It needs more legacy alias names. I found the following alias has to be included.

fix build failure

update brief documents for Elm_Textpath.

Uh oh.... I didn't modified copied documents. LOL.
Please, review only its purpose. I'll update documents if the patch is acceptable.
If it is not acceptable, I'll abandon this and maintain this in Tizen platform only.

ping~

@YOhoho
Thank you for patch. There are few things to check.

1. Please , put bracket on both conditions of if in edje_util.c. Normally, EFL puts brackets both side if we needed it.
2. Please, test your new test case with new condition for edje_recalc_do(): avoiding calling edje_recalc_do() when Edje is not dirty.

Init and free locale in eina_init, eina_shutdown

@vtorri
Thank you for good opinion. I'll update it.

So, is this OK?
If I need to check it more, please let me know.

update the document

@vtorri
I don't agree renaming internal functions to new/del. Actually, _get function just return static locale variable. new/free or new/del makes confuse people.

update the following things.

fix build failure from Windows OS

@vtorri
Thank you. I missed your comment in the previous update.

fix build error Windows OS.

add a simple test case

fix build error in Windows OS.

fix a tiny code indentation

remove changes of Evas Textblock

@zmike
Ok. Then, I'll split changes of Evas Textblock into an another patch after applying this.
Also, I'll update commit message with @feature tag.

add eina_convert_strtod_c API and apply it to evas_object_textblock

Thank you for review!

And please check a similar legacy type support from the Efl.Ui.Button.

Thank you for review!
It was generated by Eolian of efl 1.16.0. (Tizen 4.0)
I attached a generated .eo.legacy.h file of the Textblock.

@herdsman
Thank you for quick review! :)
I feel EFL became really hard to maintain recently.
After applying new interfaces into legacy code and legacy API.
It is not your fault but the strategy for new interface implementation.
Anyway, thank you for review!

We are struggling to fix the issues caused by recent upstream patches..
Please, add test cases when you guys try to change existing behaviors even if you are a committer.

I passed the patch file to @smohanty to push it directly.
So, I abandon this.

@herdsman
Thank you for quick review!

Remove an irrelevant change from test_entry.c

@herdsman
Thank you for comment.

Update the following things...

1. Add/Apply a helper function for creating "grapheme_breaks".
2. Add/Apply a helper function for reducing code duplication of prev/next function.

Then, I can abandon this patch! :)

I also added a debugging code in this patch which is disabled for default.
I think I has to maintain this widget instead of @thiepha.
So, please, just submitted debugging code with the patch. For my debugging convenience.

Remove a wrong comment

Removed: uniniialized value is used in loop condition statement.

• Before

• Before:

Rebase!

Remove inline comments.

@herdsman
Thank you for comment.
As I know, you used _edje_part_fetch() function at that point to check the given part is TEXT or TEXTBLOCK part.
In legacy, edje_object_part_text_get() used to checked the given part type.
But, after applying efl_part() concept, efl_canvas_layout_part_* checked part type before doing something.
So, only for legacy API, the type has to be checked manually like now.

@herdsman
Good point! :)
As you said calling _evas_textblock_changed() in render_pre() with delete_me=2 states caused the problem.
But, with current paragraph direction API architecture (INHERIT feature without additional API), there was no way to avoid to calling _evas_textblock_changed() function.
The textblock/text object needed to catch changes of its smart parent's paragraph_direction when its render_pre() was called.
So, I think I can put a additional condition before calling _evas_textblock_changed().

@herdsman
I found it is reproducible in upstream. But, not for Textblock obj.

Entry 'unfocused' callback called
Entry 'focused' callback called
Entry 'unfocused' callback called
ERR<7098>:evas_main lib/evas/canvas/evas_object_image.c:1320 _efl_canvas_image_internal_efl_object_destructor() SYB:: IMAGE destructor START!! ... obj[0x4000009f9201] delete_me[0]
ERR<7098>:evas_main lib/evas/canvas/evas_object_image.c:1327 _efl_canvas_image_internal_efl_object_destructor() SYB:: IMAGE destructor DONE!! ... obj[0x4000009f9201] delete_me[1]
ERR<7098>:evas_main lib/evas/canvas/evas_object_image.c:1320 _efl_canvas_image_internal_efl_object_destructor() SYB:: IMAGE destructor START!! ... obj[0x4000009f9a03] delete_me[0]
ERR<7098>:evas_main lib/evas/canvas/evas_object_image.c:1327 _efl_canvas_image_internal_efl_object_destructor() SYB:: IMAGE destructor DONE!! ... obj[0x4000009f9a03] delete_me[1]
ERR<7098>:evas_main lib/evas/canvas/evas_render.c:928 _evas_render_phase1_object_changed_normal() SYB:: PUSH a deleted object to STACK ?? obj[0x4000009f9201][image] delete_me[2]
ERR<7098>:evas_main lib/evas/canvas/evas_render.c:928 _evas_render_phase1_object_changed_normal() SYB:: PUSH a deleted object to STACK ?? obj[0x4000009f9a03][image] delete_me[2]
ERR<7098>:evas_main lib/evas/canvas/evas_object_image.c:2275 evas_object_image_render_pre() SYB:: WTF ... obj[0x4000009f9201] ... delete_me[2]
ERR<7098>:evas_main lib/evas/canvas/evas_object_image.c:2275 evas_object_image_render_pre() SYB:: WTF ... obj[0x4000009f9a03] ... delete_me[2]
Entry 'focused' callback called

@herdsman
Yes, I checked it many times. The render_pre() was called after processing its destructor function.
And when I checked delete_me flag in the render_pre() function, it was 2. (obj->delete_me)

The main question of this patch is...
An object's render or render_pre functions could be called after processing its destructor function?

@herdsman
Right now, it is reproducible when only elc_popup is deleted in Tizen.
Of course, elc_popup has a lot of custom code for Tizen UX.
If I get a reproducible case in upstream, I'll write the scenario.

A render_pre function could be called after processing an object's destructor function.
Here is a log of that problem case.

@cedric
Sorry, but I think [(int) pos < 0] and [pos > INT_MAX] are same in this case.

I moved the fix from Elementary to Edje.
It also remove negative position feature from Edje's legacy API.

@herdsman
Actually, the issues caused by cursor next/prev/up/down are pretty bad for us.
I need to hurry to apply this to Tizen. So, I'll cherry-pick it to our code.
Please, let me know if you have additional requirements.

make it pretty

fix usage of Efl_Part

@herdsman
Thank you for comment!

In Tizen, we reverted it for resolving backward compatibility problems.

Update the following things.

1. Remove configure option for glyph-lru feature.
2. Remove additional lru list only for colored glyphs.
3. Change Eina_Inlist to Eina_List as glyph lru list.

Thank you for comment! I was out of office for a while.
I'll update it soon.

We definitely don't want to "enable/disable" this. It's an optimization. Don't use the #ifdef here.
I would remove the EINA_INLIST in the glyph struct and use an eina_list for the caching, intead of an eina_inlist. That will save up some space.

It's an another trade-off. I wanted to set a limit for memory consumption by glyph with minimum performance drop.
Font's lru list is just Eina_List. It is acceptable because generally Evas don't load fonts above 100 or 1000 font files.
But, Evas can load thousands glyphs from different fonts. (CJK langauges, Emojis and reshaped glyphs by harfbuzz)
So, I thought searching a plain list to remove an glyph in worst scenario looks bad. And I decided to do not use Eina_List for this feature.

Did you benchmark this? The benefit of the inlist is when you iterate on the list a lot on the same stored data. Here you only push/pop the glyph entries in the list.
"Thousands of glyphs" is my reasoning here, too. It's extra list data (pointers) for every glyph, whether it's in a list or not.

No, I didn't benchmark about Eina_List.
But, the patch do push(In unref)/pop(In trim) and remove a random glyph from the list (In ref) which is requested to reload before trimmed.
It needs a lot of random accesses of glyph items from the list. More than pop(trim). That's why I implemented it as Eina_Inlist.

@herdsman

We definitely don't want to "enable/disable" this. It's an optimization. Don't use the #ifdef here.
I would remove the EINA_INLIST in the glyph struct and use an eina_list for the caching, intead of an eina_inlist. That will save up some space.

It's an another trade-off. I wanted to set a limit for memory consumption by glyph with minimum performance drop.
Font's lru list is just Eina_List. It is acceptable because generally Evas don't load fonts above 100 or 1000 font files.
But, Evas can load thousands glyphs from different fonts. (CJK langauges, Emojis and reshaped glyphs by harfbuzz)
So, I thought searching a plain list to remove an glyph in worst scenario looks bad. And I decided to do not use Eina_List for this feature.

fix wrong and complex condition from the head of "evas_common_font_int_cache_glyph_get" function.

@cedric
Thank you for reporting the issue.
I fixed the test code of this patch according to recent changes.

Updated the following things.

Update the following items.

@herdsman
I applied the latest unibreak library and its grapheme cluster feature for the patch.
Please, give your opinion! :)

@cedric
Changing existing "finger_size" will affect to whole UX - GUI not only the sensitivity of elm_gesture.
Because, it restricts minimum size of all widgets.

@cedric, @herdsman
If you need the font which I tested, please let me know!

@cedric
Thank you for comment!
It would be better to separate the lru list into two lru lists (bucket) for colored emoji and normal glyphs.
Actually, it was created to release emoji glyph's memory. So, I can change it as your comment.