This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

Update Docs

@segfaultxavi @woohyun
what is the usage of const(string) ?
I used "string" type because it is evaluated to "const char *" (see old property in canvas text called bidi_delimiters also use "string" type for "const char*" , for "char *" usually "mstring" used, maybe I'm wrong ? )

Rebase

@zmike
any other comments?

Rename style_set to style_apply
Make all_styles_get read only property

We have closed all the requests.

Update function description
Fix code convention
add more tests

rebase

• fix implicit casting int to a unsigned
• int added EINA_SAFETY_CHECK
• update docs

• fix implicit casting int to a unsigned int
• added EINA_SAFETY_CHECK
• updated docs

• fix implicit casting int to a unsigned int

can you check that all branches of the parsing function is checked and tested (also with asan enabled)?

I have tested only new code.

• split style property to set/get functions + fix docs

• split style property to set/get functions + Fix docs

• split style property to set/get functions

update macro to avoid unexpected behaviour

@tasn
I didn't understand exactly what do you mean by "a new widget" ? do you mean all new interface stuff (ex : ui_text) or something else ? if so, no need to work on bugs related to the new interface ?

@tasn
At least it is not working for EFL_UI_TEXT_EVENT_CHANGED_USER event for selection in ui_text (i think there is others).
This is the code used in ui_text :

This patch will solve a bug I found in efl_ui_text.
efl_ui_text can't get the focus using mouse clicks when not focused.
mouse clicks will never move focus to efl_ui_text because efl_input_processed_set(pointer, EINA_TRUE) will make event flag = EVAS_EVENT_FLAG_ON_HOLD.

@cedric @zmike any comments?

@bu5hm4n
For example "_elm_entry_efl_access_text_string_get" function in elm_entry.c
call word end then call next character for "EFL_ACCESS_TEXT_GRANULARITY_WORD" case.

@bu5hm4n
This is what I thought also, but when I saw textblock test code i thought that this behavior are intended to be like this.
anyway in GTK word end for 'hello' is 5 not 4.
So I need to fix word end bug and remove all workarounds for it and commit it as a new patch

@bu5hm4n
It sounds a little bit wrong to me also but in "evas_test_textblock" they check word end to be 4 not 5 (not exact values but same case).
For elementary_test -to "Entry 4" i didn't see its code but it seems like it uses entry, entry does not export functionality for word end I think.
I already saw some code in entry for word selection or moving cursor by Ctrl+Arrow, it calls textblock word end then move to next character :)

@bu5hm4n
based on current behavior
If cursor at position zero or middle of the word and asked for word start and end , word start is 0 and word end is 4 (see case 3)
but if cursor is at position 5 (for the same word) and asked for word start and end, word start is 0 and word end is 5 (see case 1 & case 2)
based on this behavior I expected the word start to be 5 because we are on position after the word end which is 4, so word start & end needs to be 5.

Removing unnecessary variable