This actually may help a friend of mine who has been trying to get the
mudder application to work, I think this may be a QT app. Yes, the
control could be much better labeled, it should say something like,
enable access for assistive devices and third party software. Better
yet, just remove the option entirely and have it always enabled,
there's really no advantage to having that turned off that I know of.
Original message:
Hi Mike
In a way, it's for both. Hardware devices and their associated drivers
face the same challenge as third-party toolkits, i.e. they can't
typically plug into the low-level accessibility API. I agree that the
option could be better labeled or, failing that, much better documented
as to its intended purpose both by Apple and in the QT documentation.
It's obscure enough that just finding technical documentation on how
this option works was a time-consuming search, and it was finding said
documentation that clued me in to the problems with QT.
On Oct 14, 2012, at 7:32 PM, Mike Arrigo <n0...@charter.net> wrote:
Interesting that enabling access for accessible devices would make a
difference here, you would think that would be for hardware devices not
for tool kits.
On Oct 14, 2012, at 7:45 PM, Jacob Schmude wrote:
Hi all,
A while back I posted a question on this list about applications
written with the QT GUI toolkit. They worked on my previous Macs but
not my current one. After a lot of fiddling around, I know have a
solution to get QT applications working as they once did:
You need to go into System Preferences/Accessibility (Universal Access
for those of you not upgraded to Mountain Lion). At the bottom of the
window there is a checkbox labeled "Enable Access for Assistive
Devices." This is unchecked by default. You need to turn this on and,
once you do, OS X will prompt you for an administrator password. Enter
it and then load up a QT application. They will now work as before.
Caveats:
This will only enable basic accessibility in QT applications that are
compiled with accessibility enabled and bundle the QT accessible
widgets plugin. This means that it will not enable access to every QT
app. Further, QT's accessibility support is extremely basic. Controls
such as buttons, lists, radio buttons, and edit fields will speak. Some
more advanced controls, such as tree views or custom widgets, will
still be rendered as unknown to Voiceover. QT 5.0 is set to use a more
updated Cocoa-based API to expose this information and is also set to
expose controls such as tree views. However, QT 5.0 is still in early
development and is not widely used as of now.
Applications I've tested:
* TeamTalk 4.4: Works well except for the user/channel list, which is a
tree view.
* Rockbox Utility: Works fine save for the devices tree view, though
you can get around this by selecting the path of your device manually
and having the utility detect which device you're dealing with.
* VirtualBox: Does not bundle the accessible widgets and will not load
them, so does not work. Command-line use will still allow you to use
it, but can take time to learn.
* Calibre (Ebook manager and converter): Same as Virtualbox though,
being open source, I may try and rebuild it with the appropriate flags
and plugin included. At the moment I use the command-line for ebook
conversion, which takes a bit of manual setup.
* Mumble: Does not bundle the accessible widgets and has no
command-line equivalents. Unuseable.
Technical Explanation:
QT version 4.0 implements basic OS X accessibility, but it does so via
the Carbon API, which is now deprecated. Enabling this option allows
older and third-party toolkits to communicate through the OS X
accessibility API. In a sense, it installs a bridge between the native
Cocoa accessibility API and non-Cocoa toolkits that wish to access it.
This is off by default, and simply turning on Voiceover does not change
the status of this option. This also enables a great deal of
Applescript controls for UI elements in applications that are not
normally scriptable, as well as installing additional keyboard hooks
for advanced typing utilities. It is off by default, from what I can
tell, because there is a theoretical security risk associated with
this, e.g. if you unintentionally installed a key logger trojan.
However, I know of no actual security risks in the wild relating to the
use of this option.
I hope this helps anyone out there having the same trouble I was. It
took quite a while to find this, as there is not much documentation on
the subject.
Jake
--
You received this message because you are subscribed to the Google
Groups "MacVisionaries" group.
To post to this group, send email to macvisionaries@googlegroups.com.
To unsubscribe from this group, send email to
macvisionaries+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/macvisionaries?hl=en.
--
You received this message because you are subscribed to the Google
Groups "MacVisionaries" group.
To post to this group, send email to macvisionaries@googlegroups.com.
To unsubscribe from this group, send email to
macvisionaries+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/macvisionaries?hl=en.
--
You received this message because you are subscribed to the Google
Groups "MacVisionaries" group.
To post to this group, send email to macvisionaries@googlegroups.com.
To unsubscribe from this group, send email to
macvisionaries+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/macvisionaries?hl=en.
--
You received this message because you are subscribed to the Google Groups
"MacVisionaries" group.
To post to this group, send email to macvisionaries@googlegroups.com.
To unsubscribe from this group, send email to
macvisionaries+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/macvisionaries?hl=en.
