I see and agree with it,
We do not purposely want to support legacy string strings, but it is just a side effect when update shared code between legacy and unified (it is not a bad side effect).
I am afraid this will complex the code a bit especially in future if we want to maintain two parts for parsing styles or adding new tags. right now this is just rename for the same tags nothing is new,
Are you still feel it is important to separate the tags names for legacy and unified, which effect code simplicity and backward compatibility?

Lots of EFL classes do not have an "owner" (because the original writer left, for example). Who would check those?

I think if any beta class is going to stabilize, we can recommend using this new structure. for released classes it is too late unless we want do not care about compatibility support.

Legacy style tags must be used only with legacy objects, and unified tags must be used only with unified objects.

I think this is a matter of updating legacy documentation to support new tag names.
but I do not see why the must is used in here, what if unified already understand legacy deprecated tags, what is the problem with that?

To clear things up, this patch talks about: how we parse style string only

My opinion this approach is fine since it already:
Keep legacy work as expected.
New api work as expected + support old deprecated legacy attributes

@woohyun @segfaultxavi
Can you close this one?

I thought everyone likes the Idea for using more generic type for range. even If one type using it, the other option is that this type will have its own unique type (which is against the first assumption for using generic type).

rebase

Can we move this into stabilization ? I think everybody already likes the idea

update

update

update

• update

@bu5hm4n @segfaultxavi done at D11153

update

init watch sel value

@cedric any more requests ?

@bu5hm4n @segfaultxavi @stefan_schmidt
If anyone one of you can run on this test on this patch with many many thanks :)

remove empty lines

clean up + update

update

update selection

• fic typo

done

• update

• use inline functions

In D11133#210813, @cedric wrote:

The compiler can only inline function in files it sees directly when compiling a unit. That is why wine has so many eina_inline*.x files.

remove all freeze events

In D11133#210808, @cedric wrote:

Maybe we might want all this function to be inline, other than that it looks good to me.

rename eina_range_max_get into eina_range_end

• update

update document

I think we should call this new type Efl.Range which is the default range (and I agree with what @cedric says, there should not be more ranges other than this one)

• update to remove if(top) check

It feels weird tu remove functionality that was in legacy. I would keep input_hint as Beta and rename it to input_content_type, but not remove it.

D11130

Is it possible to annotate interface implemnetaiton as @beta ? (this is for file interface)

rebase

add more test cases

update have_selection changed when reduce selection area

rebase

rebase

add Eina_Int_Range

@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)

In D11095#210335, @woohyun wrote:

@ali.alzyod Please check my inline comment :)

update

In D11115#210284, @woohyun wrote:

@YOhoho Thank you very much :)

@ali.alzyod
Could you remember this thing while doing text interface work ? :)
Thanks in advance.

• update

rebase

This should be ready for stabilization , any more comments?

move create_text_cursors and content_set into efl_ui_widget_theme_apply