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