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




The gnome-shell focus caret tracker does something similar on a caret move 
(check the current offset, then get the character extents at that offset). 
Currently, that requires two calls, but we could add API to allow the 
extents of the character at the caret to be returned in one call, or sent 
along with a caret-moved event. This would be especially useful for 
gnome-shell where it is a very good idea to avoid making synchronous 
calls
 Yes the text interface is making two calls, one after the other but it is the
call to component interface causing trouble in gnome-shell.

The current atspi timeout in dbind seems to only happen as an atspi interface
 (i.e the component interface) and some outside interface belonging to (clutter? 
Not atspi anyway) are calling DBus (synchronously, I guess) as was mentioned (below):


If allow_sync is FALSE, then AT-SPI will throw an exception rather
than make a synchronous call. This could be used when it is desirable
to guarantee that no synchronous calls are made (probably anything
running inside gnome-shell would want this, since otherwise it can
deadlock if it queries an application which is in turn making a
non-AT-SPI-related D-Bus call to gnome-shell).

I don't get this. As far as I understand the proposal, the idea of this
new API is providing an async call to get data. So when that sync call
will be called ?

Also confused about where 'allow_sync is FALSE' is set? Can you
point to where that is done, please? 

For instance, _updateFocus() in magnifier.js would have something like 
this:

Atspi.query_accessible (event.source, lang.bind(this, _updateFocusCb), 
false, false);

The logic would be moved to _updateFocusCb, and an exception would be 
thrown if _updateFocusCb were to make a synchronous call. If it is 
requesting data that it needs, then it should be added to the data sent by 
atspi_query_accessible() so that a synchronous call is not needed. This 
would guarantee that we are not making synchronous calls / creating the 
possibility for deadlocks.

The atspi callback is in the focusCaretTracker code. The
magnifier updateFocus/Caret are just delegates of the focusCaretTracker 
instance in the magnifier

Possibly Off topic, but maybe not:
I am noticing mouse freezes in the magnifier since 3.10 (could be older) They seem 
to happen for about 10 seconds or so but bizarrely, seemed to coincide with 
this message (for those who are not familiar: the mouse is from clutter -so this is a bit weird): 

 "Window manager warning: Log level 16: AT-SPI: Error in GetItems,
sender=org.freedesktop.DBus, error=The name :1.0 was
not provided by any .service files"

I am not sure if anything else but the mouse is freezing or what
triggers these freezes either yet. It is hard to recreate (could 
the mouse calls be the thing clashing with focus/caret atsi ones?)
if so that might make things easier. It could be a
total coincidence, or not. 

I think it might be good to raise a bug

_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel gnome org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]