- User Since
- Nov 27 2018, 12:22 AM (60 w, 3 d)
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
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).
Wed, Jan 22
Can we move this into stabilization ? I think everybody already likes the idea
Tue, Jan 21
init watch sel value
@cedric any more requests ?
remove empty lines
clean up + update
Mon, Jan 20
- fic typo
- use inline functions
remove all freeze events
rename eina_range_max_get into eina_range_end
Sun, Jan 19
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.
Is it possible to annotate interface implemnetaiton as @beta ? (this is for file interface)
add more test cases
update have_selection changed when reduce selection area
Fri, Jan 17
@segfaultxavi I suggest we create TASK for future work related to this class, It will need more APIs and design
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)
Thu, Jan 16
This should be ready for stabilization , any more comments?