Re: How to support dictionary service in a custom text view?
On 08/07/08 12:16 AM, Charles Srstka [EMAIL PROTECTED] wrote: Yes, but I think this check box is not relevant to this functionality. At any rate, my accessibility methods get called when I type command- control-D, whether the check box is turned on or not. If I comment out my Accessibility support, the dictionary service fails to work whether the check box is on or not. But VoiceOver is a trusted app, and (I'm guessing) that the Dictionary Service might use a trusted app to obtain info via accessibility, or its component makes the process it's loaded into trusted (temporarily). So they will always get results, whether access is enabled or not. My understanding is that the check box only enables certain advanced parts of the Accessibility API which allow the user to manipulate the UI. The basic accessibility stuff, just to read the screen and such, doesn't require that check box to be on. I think that VoiceOver uses the Accessibility API to read text on the screen, and it doesn't need that check box to be enabled in order to work. I just commented out all the AXAPIEnabled() tests in my app (actually, it's an input method component, much like the Dictionary service), then disabled access, and got nowhere. The only calls that succeeded were AXUIElementCreateApplication() and AXObserverCreate(). But any attempt to actually obtain anything via accessibility (AXUIElementCopyAttributeValue...) failed with kAXErrorAPIDisabled. So for untrusted apps (anything not from Apple, for the most part), disabling access for assistive devices, well, really does disable it! It doesn't unless my Accessibility code is there. It probably should, though - otherwise all you're seeing is the Dictionary service taking advantage of it's power to get something it needs via accessibility. It tries a number of things to both succeed and get the best attribute and positioning information it can from the underlying app. If accessibility fails, it tries TSM, and vice-versa. But it definitely doesn't *require* that the app implement the various text-related accessibility support. For example, it works fine in BBEdit (a Carbon app), access enabled or not, as BBEdit does not support access to its document's textual contents via accessibility at all. But it's got great support for text input via TSM/TSM DocAccess CarbonEvents. Anyway, what you've got now is perfectly fine if you're only concerned with the Dictionary service working. AFAIK, other than my app, there's nothing untrusted out there that makes use of the same TSM/NSTextInput and accessibility APIs to do something similar to what the Dictionary does. If you'd like a copy of my product to test with, I'd be happy to oblige (off-list). It's in my interest (even more so) to make sure it works with custom text editing views, especially if it will be used in a publicly-available product. My product works best with access enabled, but will work fine if all that's available to is the necessary TSM/NSTextInput support Thanks, Evan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: How to support dictionary service in a custom text view?
On 03/07/08 3:26 PM, Charles Srstka [EMAIL PROTECTED] wrote: On Jul 3, 2008, at 12:03 PM, Charles Srstka wrote: Okay, so I've got a custom text view that's a subclass of NSView (not NSTextView). I've followed the instructions on this page: http://developer.apple.com/documentation/Cocoa/Conceptual/InputManager/Tasks/ TextViewTask.html#/ /apple_ref/doc/uid/20001040 I override acceptsFirstResponder to return YES, I override keyDown: to call interpretKeyEvents:, and I've implemented the NSTextInput protocol. I override all the mouse events and send those to the current input manager if it wants them (it never does). I even told the NSWindow to accept mouseMoved: events so I could forward them if the input manager wanted them (it doesn't). I've also implemented Services support, accepting NSStringPboardType data and providing it to services. Anyway, this all works great for the most part. Text editing works fine, services work fine, everyone's happy, except for one thing - I want that dictionary widget that NSTextView has when you type command-control-D with the mouse hovering over a word. Since this is a system service and seems to get loaded into every Cocoa app, there must be a simple way to get my view to support it, but I'm drawing a blank as to what it is. I'm sure it's something simple, I'm just not sure what's the remaining piece of the puzzle that I need to implement. Anyone know what I'm forgetting? Never mind! I found the answer to my own question - I needed to implement the NSAccessibility protocol. I've done that, and now it works. Charles While supporting AX is always a good thing to do, the Dictionary service doesn't require access to be enabled. Have you tested at all with accessibility off? My product (well, the new version I'm working on) makes heavy use of the same TSM and AX APIs that the Dictionary service uses (and a few other). I'd be very interested to see a custom NSView that's not derived from NSTextView that supports these APIs (to know that someone has done it!). Feel free to contact me off-list if this interests you as well... Thanks, Evan Gross -- Evan Gross, President, Rainmaker Research Inc. Developers of Macintosh and Windows Software Spell Catcher for Mac OS and Windows http://www.rainmakerinc.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: How to support dictionary service in a custom text view?
On 07/07/08 11:14 PM, Charles Srstka [EMAIL PROTECTED] wrote: I'm not sure what you're referring to with regards to accessibility off. If you are referring to the Allow access for assistive devices check box in the Universal Access preference pane, that isn't what I was talking about at all. That is what I was talking about. The Dictionary service will work if Allow access for assistive devices is deselected (off). What I did was implement the methods in the NSAccessibility informal protocol such as accessibilityAttributeNames, accessibilityAttributeValue:, accessibilityAttributeValue:forParameter:, and the rest. Implementing these after having implemented NSTextInput caused the Dictionary service to start working with my custom view. Sure, but when Allow access for assistive devices is deselected, those methods will (should!) not be called. I know that the Dictionary service *does* apparently make use of the accessibility APIs, as if I set a breakpoint in the accessibility methods, they get called quite a bit when one invokes the Dictionary service via command-control-D with the mouse cursor over my view. Sure, it uses (possibly requires) NSTextInput (TSM document access events) support, and (optionally) accessibility to do it's thing. If accessibility isn't available (Allow access for assistive devices deselected, or the app/editing view doesn't support access to text via accessibility), the Dictionary service will work using only NSTextInput. See what happens if you deselect Allow access for assistive devices - as long as your NSTextInput implementation is complete (enough for the Dictionary service, anyway), it should still work. Evan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: How is Apple + Ctrl + D implemented?
On 30/04/08 11:00 AM, Nathan Vander Wilt [EMAIL PROTECTED] wrote: What none of this explains is why Preview.app won't give a pop-up dictionary even when a PDF has selectable text (which can be pulled up in Dictionary.app). For me, that would be an interesting explanation to hear. A good question (it would be nice if the Dictionary panel worked in PDF views), with a simple answer: Preview (or at least the view it uses to display PDFs) simply doesn't implement the necessary TSM/TSM Document Access/Accessibility support needed by the Dictionary service. (/System/Library/Components/DictionaryService.component) Maybe it's time to file an enhancement request... Evan Gross -- Evan Gross, President, Rainmaker Research Inc. Developers of Macintosh and Windows Software Spell Catcher for Mac OS and Windows http://www.rainmakerinc.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: How is Apple + Ctrl + D implemented?
On 28/04/08 1:55 AM, Ying Bian [EMAIL PROTECTED] wrote: I am thinking of developing my own dictionary tool which can detects the word under the cursor and automatically (or when a modifier key is pressed) popup a translation window. After researching for a while, I find it more tricky than I estimated. If you search the Cocoa Dev and Carbon Dev archives for dictionary panel, dictionary popup or dictionary service, you should find some useful information. And you are correct, implementing something like it is (to understate) a non-trivial task. The accessibility APIs may of help, but for text in a text view, the returned information is not enough to reproduce the layout and let me detect the exact word over which the mouse hovers. There is a similar functionality in Lepoard (I am not sure if it exists prior to 10.5): It does, definitely in Tiger, not sure about Panther. The required APIs first appeared in 10.3. in any cocoa-based applications, if you press Apple + Ctrl + D, the current word under cursor is automatically selected and translated in a popup window. It seems to me not implemented with accessibility APIs as it does not require to enable access for assistive devices in the Universal Access System Preference panel. This works in many Carbon apps as well. Strictly speaking, it has nothing to do with Carbon vs. Cocoa. It depends entirely on the capabilities of the text view/area/engine. It works just fine in BBEdit, for example. Then, how is this implemented? I want to get some hints from this. The Dictionary panel is a special type of input method component: /System/Library/Components/DictionaryService.component It uses Text Service Manager (both regular TSM and TSM Document Access) and Accessibility APIs to determine the text (and its attributes) under the mouse. It will use various combinations of TSM/AX APIs to get the best representation available from the underlying document. If you look closely, the results are often slightly different with Universal Access on vs. off. It does not use any Cocoa APIs (as suggested in some other replies) for this purpose. Reading up on TSM and input method components is the proper starting point for what you want to do. Hope that helps, Evan Gross -- Evan Gross, President, Rainmaker Research Inc. Developers of Macintosh and Windows Software Spell Catcher for Mac OS and Windows http://www.rainmakerinc.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
