After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 649123 - Create desktop-agnostic way to identify active/running ATs
Create desktop-agnostic way to identify active/running ATs
Status: RESOLVED OBSOLETE
Product: at-spi
Classification: Platform
Component: at-spi2-core
unspecified
Other Linux
: Normal normal
: ---
Assigned To: At-spi maintainer(s)
At-spi maintainer(s)
Depends on:
Blocks: 638537
 
 
Reported: 2011-05-01 22:28 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2021-07-05 10:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Joanmarie Diggs (IRC: joanie) 2011-05-01 22:28:18 UTC
Could and should there be some desktop-agnostic way to find out what ATs are active (by which I mean currently running) for the current desktop?

Hypothetical use cases:

 * Orca could provide access to KDE and is happy to do so, but if
   Korca (hypothetical screen reader for KDE) is running, Orca
   should let Korca do its thang in its own environment.

 * Two magnifiers running at the same time would be a bad idea.

 * A DE could have an option whereby caret navigation is toggled
   on automatically if a screen reader is currently running.

 * If Orca detects a magnifier is running and flat review is being
   used (i.e. no focus changes or caret moving; just reviewing the
   screen), Orca should do something to let the magnifier know
   where the region being reviewed is, because there's a very good
   chance that what is being reviewed will fall off screen.

 * If speech recognition is enabled and a screen reader is also
   enabled, <insert magic foo here> makes it possible to speak
   desired screen reader commands (so 'next line' would move the
   caret to the next line within the document causing the screen
   reader to speak it; it would NOT cause the words 'next' and
   'line' to be added as new text within that document).

If we wanted to do that sort of thing currently, an app would have to know:

 * what desktop environment we're in
 * what settings tool applies in that environment
 * what the schema (or whatever) is for that tool
 * what the relevant key within that schema is

And if we know all those things, at least in GNOME, we still don't know if the AT is running or not; simply that the service associated with that AT is enabled or disabled. Maybe going through the same process in XFCE will not tell us about a service, but about the current state. Thus add "What does the 'enabled' key actually mean in the current desktop environment?" to the bulleted list above.

I think it would be nice if we could just ask the accessible desktop if an AT of type X happens to be running at the moment.
Comment 1 Li Yuan 2011-05-09 10:59:00 UTC
This reminds me that we should have an interface in at-spi2 which like login-helper in at-spi. Screensaver can use this interface to know which ATs are running and try to put them on the top of the screen. I think this is a similar work.
Comment 2 Joanmarie Diggs (IRC: joanie) 2011-05-28 23:05:06 UTC
ATK Hackfest conclusions: https://live.gnome.org/Hackfests/ATK2011/Agenda/client-registry
Comment 3 André Klapper 2011-06-23 22:07:03 UTC
[Mass-reassigning open atk bug reports for better trackability as requested in https://bugzilla.gnome.org/show_bug.cgi?id=653179 .
PLEASE NOTE:
If you have watched the previous assignee of this bug report as a workaround for actually getting notified of changes in atk bugs, you yourself will now have to add atk-maint@gnome.bugs to your watchlist at the bottom of https://bugzilla.gnome.org/userprefs.cgi?tab=email to keep watching atk bug reports in GNOME Bugzilla.
Sorry for the noise: Feel free to filter for this comment in order to mass-delete the triggered bugmail.]
Comment 4 Carolyn_MacLeod 2013-04-23 21:20:52 UTC
In case it's useful, on Windows an app can check if an AT is running by looking at the SPI_GETSCREENREADER bit in SystemParametersInfo:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724947(v=vs.85).aspx
(It works for any AT, including system magnifier that comes up with "Windows key+Numpad_plus"). It is the responsibility of the AT to set/clear the bit using SPI_SETSCREENREADER in SystemParametersInfo. The app can listen for WM_SETTINGCHANGE to be notified of setting changes.

On Mac, VoiceOver has a flag called "voiceOverOnOffKey" in NSUserDefaults standardUserDefaults. You need to addSuiteNamed: "com.apple.universalaccess" and synchronize, then use integerForKey: "voiceOverOnOffKey" to retrieve the flag.
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
I believe VoiceOver sets/clears the flag using setInteger:forKey: when it starts/exits.
Comment 5 Alejandro Piñeiro Iglesias (IRC: infapi00) 2013-04-24 11:33:17 UTC
(In reply to comment #4)
> In case it's useful

Thanks for the feedback. Yes, comparing with what others are doing is always a good source of information. We want to do with anything that is broken (or just need some improvement) on our framework. Having the comparison done by someone more experienced on those others are always good.

Having said so, I think that we already included some of this stuff, at least on at-spi2. I will reassign this bug, so Mike Gorse (at-spi2 maintainer) can provide some feedback of the current status of this bug.
Comment 6 André Klapper 2013-08-14 10:08:53 UTC
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
Comment 7 GNOME Infrastructure Team 2021-07-05 10:45:48 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/

Thank you for your understanding and your help.