Re: insertText: without a NSWindow/NSView (or: Unicode input without NSView/Window)

FROM : Aki Inoue
DATE : Wed Jan 30 19:38:06 2008

The object that's interacting using NSTextInput protocol is the first 
responder in key window.

When you're inputting complex scripts like Japanese or Chinese, the 
input methods need to display supporting panels around the text input 
object so you need to have visual representation closely tied to 
NSWindow/NSView relationship anyway.

Once you implement NSTextInput protocol, you don't have to distinguish 
printable characters by yourself.
The actual user input text comes in -insertText: and other non-
printable events in -doCommandBySelector:.

Aki

On 2008/01/30, at 3:02, Ken Thomases wrote:

> On Jan 30, 2008, at 2:31 AM, Adam Zegelin wrote:
>

>> On 30/01/2008, at 7:21 PM, Ken Thomases wrote:
>>

>>> Why do you not process all of the characters in the event?  In 
>>> other words, [[even characters] length] may be greater than 1. 
>>> There should be a COMBINING ACUTE ACCENT (u0301) character 
>>> following the "e".
>>>
>>> If the game engine needs precomposed characters, then you can call 
>>> -[NSString precomposedStringWithCanonicalMapping] on the string, 
>>> first.  Note that this is orthogonal to my previous point.  It is 
>>> _not_ guaranteed to reduce the length to 1.

>>
>> Sorry, I forgot to mention that my event handler prints [event 
>> characters] and its length (using [[event characters] length]) to 
>> the console. The length is always 1 or 0, even for composite key 
>> events. ie, the keydown event for option-e results in "" (blank) 
>> and a length of 0. The next key press (the e) just returns "e" and 1.
>>
>> So if I could get a longer character string that would be a start, 
>> but [event characters] is never longer than 1 character.

>
> Oh, oops.  Right.  I should have remembered that.
>
> There's a document titled "Text Input Management" which sort of 
> describes this area: http://developer.apple.com/documentation/Cocoa/Conceptual/InputManager/index.html
>
> In theory, your class would adopt the NSTextInput protocol and then 
> interact with NSInputManager and NSInputServer objects.  However, 
> there seems to be a significant chunk missing from the conceptual 
> documentation: how do you tell the framework that your NSTextInput-
> conforming object is the current text view.
>
> It seems that your class may still need to be a subclass of NSView, 
> and the framework would set up the proper relationships behind the 
> scenes.
>
> In Carbon this is all a lot clearer.  There are text input events 
> that get delivered, and you can handle them at the application level 
> without requiring a window.  :-/
>
> You might be able to accomplish what you need in a truly hackish 
> way: create an invisible window that accepts first responder and can 
> become key.  Put a custom (maybe NSTextInput-adopting?) NSView 
> subclass in it, and have it accept the text and pass it to your 
> controller.
>
> -Ken
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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/<email_removed>
>
> This email sent to <email_removed>