Re: [g-a-devel] AT-SPI caching and D-Bus usage

[Piñeiro <apinheiro igalia com>]

Hi Mike

Regarding the pretty arbitrary application of properties and
getters/setters, after giving some thought about this, I think that
everything that is inherent to the object, so can be requested to the
object without any extra parameter, should be a property. So applying
this to the examples of my previous paragraph, Alpha and Layer should
be also properties. It is not needed to remove the get/set
methods. They are just making public the get/set implementation for
those properties.

Regarding atspi_event_listener_register_full, initially, I was
somewhat concerned of adding this procedure. Because if some ATs were
missing some info from an event, my initial reaction was that the
problem was with the event. For example, on the case of the
text-caret-moved, we could have just extended the signal to include
the character extents. But at the same way it is true that different
ATs need different information. For example, the magnifier would be
interested in the extents of the object emitting any event of interest
for the magnifier (like state-changed:focused or
active-descendant-changed), but Orca would not. And adding the extents
on the event always sounds like an overkill. So I'm ok with going with
this path, and seeing how the APIs are used.

> From the previous paragraphs, one conclusion is that we would need to
start to add properties to at-spi2-core/xml (and to atk
etc). Properties for data that already had get/set pairs, and
properties for new stuff of interest, like ScreenExtents and
CurrentCharacterScreenExtents.

More comments inline

On 12/14/2013 12:55 AM, Mike Gorse wrote:
> > >  * @allow_sync: Specifies whether synchronous calls will be allowed
> > > during
> > >  * the execution of @callback. If this is set to %FALSE, then an
> > > exception
> > >  * will be thrown if the callback calls an AT-SPI function which would
> > >  * otherwise make a synchronous D-Bus call. Set to %FALSE in cases
> > > where a
> > >  * synchrous D-Bus call has the potential to cause deadlock (for
> > > instance, if
> > >  * the application needs to be able to respond to non-AT-SPI D-Bus
> > > calls from
> > >  * other applications). Otherwise set to %TRUE.
> >
> > We already had several sync methods, and the atspi collection. Is there
> > any reason to allow this method to be synchronous?
>
> I'm hoping that the function will be useful to Orca for building flat
> review contexts, and Orca might want to query something that is not
> available as a property.

But if that info is not available as properties, does that means that
under the callback of the asynchronous call, Orca could request even
more info through DBUS? If that is the case, that seems like a nested
D-BUS asynchronous call call. Taking into account the complexities of
how the flat review context structure, I don't see how that would work
on the practice.


> If gnome-shell were to do this, then it should not be allowed and
> indicates that we need to come up with a way to allow gnome-shell to
> get the data that it needs asynchronously, but we don't currently need
> this hard restriction for Orca, since it doesn't need to respond to
> synchronous non-AT-SPI D-Bus calls from other applications

So that means that Orca would be "allowed" to do synchronous calls
against applications like gnome-shell?

BR

-- 
----
Alejandro Piñeiro