QT. is that quicktime? web site http://www.timothyclarkmusic.wordpress.com phone number should you need to reach me 724-401-1224 check my site for more contact information. thanks and may the good lord keep you and bless you. Timothy
On Oct 15, 2012, at 12:41 AM, Jacob Schmude wrote: > 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 <[email protected]> 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 [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/macvisionaries?hl=en.
