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 _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
