Page MenuHomePhabricator

Refactor ATSPI interface
Closed, ResolvedPublic

Description

Some ATSPI interface should become internal and not be exposed to user. Overall cleanup would be necessary.

cedric created this task.Mar 30 2017, 2:45 AM

The following would be cared.

Evas_Object *elm_access_object_register(Evas_Object *obj, Evas_Object *parent)
void elm_access_object_unregister(Evas_Object *obj)
Evas_Object *elm_access_object_get(const Evas_Object *obj)
Evas_Object * elm_object_part_access_object_get(const Evas_Object *obj, const char *part)

void elm_atspi_accessible_name_set(Elm_Interface_Atspi_Accessible *obj, char *name)
char *elm_atspi_accessible_name_get(const Elm_Interface_Atspi_Accessible *obj)

void elm_atspi_accessible_description_set(Elm_Interface_Atspi_Accessible *obj, const char *description)
const char *elm_atspi_accessible_description_get(const Elm_Interface_Atspi_Accessible *obj)

void elm_atspi_accessible_translation_domain_set(Elm_Interface_Atspi_Accessible *obj, const char *domain)
const char *elm_atspi_accessible_translation_domain_get(const Elm_Interface_Atspi_Accessible *obj)

Eina_Bool elm_atspi_accessible_relationship_append(Elm_Interface_Atspi_Accessible *obj, Elm_Atspi_Relation_Type type, const Elm_Interface_Atspi_Accessible *relation_object)
void elm_atspi_accessible_relationship_remove(Elm_Interface_Atspi_Accessible *obj, Elm_Atspi_Relation_Type type, const Elm_Interface_Atspi_Accessible *relation_object)

cedric raised the priority of this task from TODO to High.Jul 10 2017, 2:57 PM

The following would be minimal set(?).

[elm_access*]
efl_ui_access_object_register/unregister

[elm_atspi*]
efl_ui_atspi_accessible_name_set/get
efl_ui_atspi_accessible_description_set/get
efl_ui_atspi_accessible_translation_domain_set/get
efl_ui_atspi_accessible_relationship_append/remove

@cedric This could be just renaming of Elm.Interface.Atspi_Accessible.
Is it possilbe to keep current interface? Or the name should be changed like others such as Efl.*?

stanluk added a subscriber: stanluk.EditedSep 5 2017, 3:25 AM

Please check first attempt to rename: D5161, D5162, D5163, D5164
I will update this task if new diffs occurs

jpeg added a comment.Sep 19 2017, 1:19 AM

As said somewhere else:

Access (atspi) is a major blocker for C++ usage as many API names clash. Could you dress a list of APIs that need to be accessible by applications, or potentially overridden by widgets?
If all APIs need to be potentially overridden, then please make a patch to prefix the names with "access_" :)

jpeg added a comment.Sep 21 2017, 7:58 PM

See also D5213
A couple of things:

  1. What about renaming elm_interface_atspi_accessible and elm_interface_atspi_widget_action?
  2. Could you just add @beta tags first to all the APIs that aren't public (i.e. not in the list proposed by @kimcinoo) ? I believe that should be enough to unlock a great part of C++ APIs.
  3. I'm not sure how to prefix the APIs :) it sounds like they should all be in the "access" namespace but I understand that the names in C would then not make any sense... hmm :(
jpeg added a comment.Oct 23 2017, 8:07 PM

@stanluk

  1. Can you rename Elm.Interface.Atspi_Widget_Action?
  2. Efl.Access.Component -> too many non-beta non-prefixed APIs that conflict with base classes (eg. "size" or "position").
  3. Many non beta APIs in other interfaces & mixins. I suspect many name clashes:
    • Efl.Access.Editable.Text
    • Efl.Access.Image
    • Efl.Access.Selection
    • Efl.Access.Text
    • Efl.Access.Value
    • Efl.Access.Window
jpeg added a comment.EditedOct 25 2017, 12:54 AM

See D5365

jpeg added a comment.Nov 1 2017, 1:14 AM

@stanluk

  • What about D5365?
  • What about elm_atspi_app_object and elm_atspi_bridge

@jpeg elm_atspi_bridge should not be renamed in my opinion, it is bridge between efl_access_* and at-spi in elementary, so name sounds sensible. What can be done is to de-EOBJECTify bridge, however I'm not sure what current politics are? Can eo be used internally?

I will rename elm_atspi_app_object

jpeg added a comment.Nov 6 2017, 5:49 PM

Yes, EO can be used internally only, no problem there.
We just need to make sure the APIs don't appear outside of elementary.

jpeg lowered the priority of this task from High to Wishlist.Jan 18 2018, 2:37 AM

Most of this has been handled already, I think, API-wise. All unstable things have been marked as beta.

Ok, please keep me informed if anything else should be changed

jpeg added a comment.Jan 18 2018, 10:05 PM

I think you're the boss.
Everything right now is marked as beta, except for:

  • Efl.Ui.Widget.access_info
  • Efl.Access.attribute_append
  • Efl.Access.attribute_clear

But the last two are actually protected behind an extra EFL_BETA_API_SUPPORT. There are some C API's inside efl_access.h as well, also behind EFL_BETA_API_SUPPORT.
In other words, nothing except Efl.Ui.Widget.access_info is stable, assuming we release the EO API.

It seems that the Efl.Ui.Widget.access_info is related to the elm_access.
I would like to create separated item for the elm_access.

@cedric @woohyun
In my point of view, thanks to @stanluk, the work for this item (Refactor ATSPI interface) is done.
I would like to colse this item if you do not have any doubts.

kimcinoo closed this task as Resolved.Apr 12 2018, 7:02 PM