Re: [g-a-devel] FocuCaretTracker issues

[Joseph Scheuhammer <clown alum mit edu>]

Alejandro,

I wrote:
> Still thinking about the rest.

I think the question of when to initialize Atspi also depends on whether 
the tracker is a singleton vs. private instances per client.

Alejandro wrote:

>   2. If calling ATSPI init can affect  users that not need the tracker:
> then the init should be done somewhere (sorry for being vague) at the
> code that starts the tracking focus if needed.

You go on to suggest that if there were a way of knowing whether 
tracking is needed, then to initialize based on that need.  You provide 
an example:

> shell_a11y_init {
>
> if (need-tracking)
>     initialize_atspi
> }
>
> need-tracking-setting-changed-callback {
>
>     if (new_value == true) {
>        initialize_atspi
>      }
>
>     if (new_value == false)
>        clean_atspi_resources;
>     }
> }

Whether tracking is needed is a user preference, and is one of the 
user's GSettings.  Furthermore, that GSetting is specific to the 
client.  For example, there is (will be) magnifier GSettings for focus 
and caret tracking modes.  Thus, the magnifier will know if tracking is 
needed, and it will create an instance of the FocusCaretTracker as 
needed.  It's at that point that it's known for certain that atspi is 
required.  That argues for putting Atspi.init() in the FocusCaretTracker 
(which is currently where it is).

On the singleton model, Atspi.init() would be called once.  On the 
multiple instance model, it will be called every time an instance of the 
tracker is created.  But, Atspi.init() is documented as:

" Returns : 0 on success, 1 if already initialized, or an integer error 
code."

The source code confirms that a check is made to see if Atspi is 
initialized, and does not execute more than once.  See line 900 and 905 of:
https://git.gnome.org/browse/at-spi2-core/tree/atspi/atspi-misc.c

It's therefore safe to call Atspi.init() multiple times.

Aside:  there is also an atspi_is_initialized() function in 
"atspi-misc.c", but it is not available through JavaScript, and it 
doesn't appear in the Atspi-2.0.gir file.  I don't why this is the case 
-- why hide it?  It has no side effects.

On the other hand, ... there is nothing preventing shell_a11y_init() 
from looking up all the GSettings and seeing if there is at least one 
setting that calls for a tracker.  It's a little less elegant since it 
involves knowing which setting(s) to look for.

In terms of quitting, FocusCaretTracker has a shutDown() method that 
disconnects all clients and deregisters all of the Atpsi events that it 
registered. The name of the method should be stopTracking().  On the 
multiple instance model, just before a client is finished with its 
tracker instance, it calls stopTracking().  On the singleton model, the 
same method stopTracking(), is called , but it's called from whereever 
gnome-shell shuts down (my turn to be sorry for being vague).

Finally, there is an Atspi.exit() method that, " Disconnects from 
AtspiRegistry instances and releases any floating resources. Call only 
once at exit".  That could be called from the same (vague) place where 
gnome-shell is quit.  Thought:  there is a shell_a11y_init().  Is there 
a shell_a11y_exit()?

Thanks.

--
;;;;joseph.


'A: After all, it isn't rocket science.'
'K: Right. It's merely computer science.'
             - J. D. Klaun -