On 07/19/2013 10:26 PM, Joseph Scheuhammer wrote:
> 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.
Yes, I agree.
>
> 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:
Yes that was my suggestion. In any case, is just a suggestion, I didn't
read the code enough to have a better idea. So if you or Magdalen thinks
that there are a best way to initialize this, you can ignore me ;)
>
>> 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.
Good.
>
>
> 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.
Well, although Mike Gorse will know better, I assume that it is hidden
for the rule of simplicity, don't expose public API that you don't need.
As calling _init several time is safer, exposing that method is not
really needed.
>
> 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.
Is a problem knowing which setting to look for? FWIW, in older versions
of shell_a11y_init, when the bridge was still a module(plugin),
shell_a11y_init used two gsettings. One in order to know if the
accessibility should be enabled (so the module loaded), and other in
order to know where the module file was placed. You can see the code
here [1]. In the same way right now gnome-shell is already checking for
some other gsettings. For example here [2].
What I try to say is that if you are concerned that any reviewer will
complain for using gsettings, I really doubt about that.
>
> 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()?
No, there isn't any shell_a11y_exit right now. In fact, AFAIK, there
isn't any exit related method on gnome-shell right now. If we need to
implement this logic is something that we need to ask to gnome-shell
developers (probably Jasper).
BR
[1]
https://git.gnome.org/browse/gnome-shell/tree/src/shell-a11y.c?h=gnome-3-2#n35
[2] https://git.gnome.org/browse/gnome-shell/tree/src/shell-app-usage.c#n960
--
Alejandro Piñeiro Iglesias
_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
