Page MenuHomePhabricator

efl.access.window
Open, TODOPublic

Description

|interface Efl.Access.Window
|├ (E) window,created
|├ (E) window,destroyed
|├ (E) window,activated
|├ (E) window,deactivated
|├ (E) window,maximized
|├ (E) window,minimized
|├ (E) window,restored
zmike created this task.Jan 8 2019, 11:51 AM
zmike triaged this task as TODO priority.
segfaultxavi moved this task from Backlog to Evaluating on the efl: api board.Feb 5 2019, 4:34 AM

This interface emits windows-related events and nothing else. My only question is why are these events in this interface, instead of directly on Efl.Ui.Win (the only class implementing the interface)?
window, minimized looks like a pretty basic window event, and not an Accessibility one.

zmike moved this task from Evaluating to "easy" on the efl: api board.Feb 6 2019, 5:36 AM
woohyun added a subscriber: stanluk.EditedFeb 9 2019, 12:20 AM

Those are special set of events for efl_access_object_event_emit.
And the method looks ... static one. (i.e. not a method for a specific object)

So, I think those events can be moved to efl_access_object.eo or some where else.
And this thing can be considered together in T7653

@stanluk @Jaehyun_Cho
Could you share your idea on this ?

@segfaultxavi
I think it all depends on how we define accessibility event. Those events are in fact defined in AT-SPI2 protocol: https://gitlab.gnome.org/GNOME/at-spi2-core/blob/master/xml/Event.xml
Generally the events from this interface translates 1-1 to dbus signals which are received by external process (screen-reader). It also serves as a flag for screen reader that this object may emit such events in the future.
The interface can be theoretically removed, however the idea was that atspi bridge should talk to objects only via efl_access_* interfaces. Instead it will require some knowledge of elementary classes. TBH i do not know if any other class will ever require to implement this interface. Only something like GIMP multi-window UI comes to my mind.
@woohyun
As a part of T7653 this interface can be removed completely and moved into efl_access_object. Additionally events can be refactored into regular methods, so instead of "window,created" we will have something like window_created_emit method or just emit with some parameter. Is this acceptable?

@woohyun
As a part of T7653 this interface can be removed completely and moved into efl_access_object. Additionally events can be refactored into regular methods, so instead of "window,created" we will have something like window_created_emit method or just emit with some parameter. Is this acceptable?

I agree with this opinion, but it's up to the final definition of efl_access_object :-)

zmike moved this task from "easy" to Backlog on the efl: api board.Mar 8 2019, 7:32 AM