OK! T8579

@segfaultxavi I suggest we create TASK for future work related to this class, It will need more APIs and design

In T8522#149737, @bu5hm4n wrote:

I am okay with the API side, only one thing impacts the API right now:

• _efl_ui_textbox_efl_layout_signal_signal_callback_add still has a problem, the object of the function callback will be wrong

what do you suggest? I look at other parts of the toolkit, and they use it the same way as in efl.ui.textbox (like efl_ui_image_zoomable and efl_ui_layout_base)

Moving to efl.player is not very difficult, but we do not yet have an agreement about whether it would be useful to do so. We need opinions!

While trying to write a Rich Text Editor sample application I have come across a problem with this API.
The user cannot RETRIEVE the attributes of a text range.
This is important to know when the "bold" button should enable or disable bold text, depending on whether the text already contains the bold attribute.

I am okay with the API side, only one thing impacts the API right now:

• _efl_ui_textbox_efl_layout_signal_signal_callback_add still has a problem, the object of the function callback will be wrong

I think this looks ok now :)

I'm also ok with current definition :)

Do we have any plans to move and implement autoplay and looping to Efl.Player?
Is there anything else I need to change in Efl.Ui.Vg_Animation before merging D10870?

This should be ready for stabilization , any more comments?

API-wise, there's not much more to discuss. Look right.

In T8522#149689, @bu5hm4n wrote:

Something else discovered due to reviewing D11107. _part_is_efl_ui_textbox_part returns valid parts for each and every part name. However, _efl_ui_textbox_text_set and _efl_ui_textbox_text_get do only work for "efl.text_guide" or "efl.text". I think we should change _part_is_efl_ui_textbox_part that it only works for "efl.text_guide" and "efl.text", for the rest EINA_FALSE should be returned.

Something else discovered due to reviewing D11107. _part_is_efl_ui_textbox_part returns valid parts for each and every part name. However, _efl_ui_textbox_text_set and _efl_ui_textbox_text_get do only work for "efl.text_guide" or "efl.text". I think we should change _part_is_efl_ui_textbox_part that it only works for "efl.text_guide" and "efl.text", for the rest EINA_FALSE should be returned.

In T8522#149647, @ali.alzyod wrote:

what is text_table, and why is it used ?

it is a container for guided text and internal interactive text

what is text_table, and why is it used ?

it is a container for guided text and internal interactive text

Yeah i think keeping it is better. The API does not look wrong, i would implement it exactly the way it is now when ding the double progressbar. Additionally, removing it, means we have to refactor quite a lot of code, which will be simply duplicated by the time we introduce the double progressbar :)

In T8501#149443, @bu5hm4n wrote:

Oh sorry - i somehow missed your reply.

True - i would then just guard the part get implementation that we can only use multiple parts when on the legacy widget, does that sounds fine ?

I agree, lets keep these @beta.

I agree with your opinion! Power_Interpolator :)

I still don't know how factories work, I cannot help much here.
If you say it is not urgent, we can keep it beta, sure.

I hope to keep "item_factory" as @beta one.
This is because current definition of Textblock_Factory can be developed with better way (T8568).

Thank you for your reply! Now I understand your point and I agree with you.

• NOW : radius_get { } for Efl.Canvas.Gesture_Zoom
• TODO : @property radius { get { } } for Efl.Canvas.Gesture_Zoom

I'm OK with stating in the video docs that autorepeat is ignored. Then again, it does not look very hard to implement either...

I've done the work to remove the events from this and put them in efl.player, so this is taken care of. We can independently evaluate the implementation of those events in existing efl.player interface users once we stabilize those events.

My point regarding autoplay/autorepeat was that they could potentially be moved to efl.player, not that they could be combined.