Re: [g-a-devel] FocuCaretTracker issues
- From: Piñeiro <apinheiro igalia com>
- To: gnome-accessibility-devel gnome org
- Subject: Re: [g-a-devel] FocuCaretTracker issues
- Date: Mon, 22 Jul 2013 13:58:46 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]