Re: insertText: without a NSWindow/NSView (or: Unicode input without NSView/Window)
Re: insertText: without a NSWindow/NSView (or: Unicode input without NSView/Window)
- Subject: Re: insertText: without a NSWindow/NSView (or: Unicode input without NSView/Window)
- From: Adam Zegelin <email@hidden>
- Date: Thu, 31 Jan 2008 18:44:55 +1100
On 31/01/2008, at 5:38 AM, Aki Inoue wrote:
The object that's interacting using NSTextInput protocol is the
first responder in key window.
I may not have a window (when the game is in fullscreen), that is my
problem.
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.
Sure, that makes sense since those input systems require complex
editing. But I can't understand why there is no way interpret
composite character events without a NSView/NSWindow system. As Ken
mentions below, you can do it in carbon.
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:.
Is there anyway to implement the NSTextInput without the implementer
also being a NSView?
On 30/01/2008, at 10:02 PM, Ken Thomases wrote:
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.
Yeah, I read that doc and drew the same conclusion. My guess is its
private.
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. :-/
I was a carbon developer but the announcements that Carbon won't be
fully 64-bit and has been "deprecated" made me move to Cocoa. If it
weren't for the announcements, I probably would have gone the carbon
route and hence I'd have this working nicely by now ;D
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.
I'll try this, but I have a sneaky suspicion that it won't work for
fullscreen. And I'll probably have to override a whole bunch of other
things to prevent the invisible window from loosing focus.
Hasn't anyone attempted to implement unicode input in a Cocoa
application where the content display is not necessarily attached to
the NSView system (ie, an OpenGL game or other 3D application). I seem
to recall that World of Warcraft implemented unicode input, but I
can't remember if its Mac OS X layer is written in Cocoa or Carbon.
Regards,
Adam
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden