It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/
This looks overall like a very good idea. We just have to remember that we still need to support atspi for legacy widgets (and thus also in the bridge).
If you remove the implementation line here, you can also remove the actual implementation .c (same for the other .eo files)
This change (and all the changes below have to support legacy as well as Efl.Ui.
The easiest would be to have :
if (elm_widget_legacy_is(obj)) efl_access_value_and_text_get(obj, &value, NULL); else value = efl_ui_range_value_get(obj);
Same applies to ELM_ATSPI_OBJ_CHECK_OR_RETURN_DBUS_ERROR.
This here is a little bit more complex, as we need to support legacy, we need to defer this if up to a point where we know for what kind of widget we are calling this, legacy or efl.ui.
This needs to support both, as we still need support in legacy for EFL_ACCESS_VALUE_INTERFACE.
|333 ↗||(On Diff #28921)|
I think this change needs to be removed. Elm_Slider is a legacy widget, that needs to keep the ACCESS functionality.
OK, I understand that we cannot fully remove Efl.Access.Value interface, since elm widgets don't implement range_display interface, which had to replace Efl.Access.Value. But what should we do in case when the widget doesn't have legacy _as well as_ range_display? Shouldn't I add after
another if statement, like this:
else if(efl_isa(obj, EFL_UI_RANGE_DISPLAY_INTERFACE))
I think that cannot happen, the APIs below are guarded with calls, that *should* only allow objects to reach that point that are either Efl.Access.Value or Efl.Ui.Range_Display. However, if you hit a case where this is not true, then you can just check with 2 if's if its Efl.Access.Value or Efl.Ui.Range, if neither, you can just raise a error. That should be enought. :)
(Btw. i also answered that via mail, did my mail not arrive?)