1

I want to add Japanese (and other language) input support to a full screen OpenGL game where the input boxes are custom rendered widgets, i.e. not NSViews.

I think adopting NSTextInputClient will allow me to take advantage of the input method, but I don't want the OS to render it's OSX style input method UI over my game as that will break continuity with the style.

Is there a lower-level API that would allow me to a.) hide the default candidate list UI, and b.) listen to events on the input method and receive the list of candidates for the text being composed, such that I can render the candidate list over my in-game text widget in the style of the surrounding UI?

JakeK
  • 61
  • 2

1 Answers1

4

Not really. If you don't want to use Cocoa views for this, you're in for a HUGE amount of kludgy work. You might have no idea how complex those things are. There are not any direct ways to just ask the built in system input methods for their conversion routines. Apple wants you to use those in the way they've been designed to be used. You might be able to pull off something with hidden views and accessibility APIs but it would be an incredible uphill battle. You'll be better off spending your effort on just figuring out how to make those fit in as best as possible and move along. The interesting thing is, users who do normally use input methods for their languages will actually feel fine and at home the consistent appearance of those input methods. Probably more so than if anybody customized those in a way they are not familiar with. Many aspects of those input methods, even if translated into English, will make little sense without some real understanding of the language that uses them.

Koteri - The Japanese input method on OS X

In this example of Koteri, you can see quite a few things that you might not be able to deal with.

The Cocoa Text System is rich, deep and complex. In general, you should adopt it rather than try to bend it. (and you'll have a lot more success with that)

uchuugaka
  • 12,679
  • 6
  • 37
  • 55
  • 1
    I agree. An input method is free to do *anything* it wants with the keystrokes and mouse events. There is no reason to expect that it's limited to showing candidate lists or the like. So, there's no reason to expect that there's some data structure (e.g. candidate strings) that's separable from the UI an input method presents such that you could present the same data in a different UI, any more than you'd expect to be able to do that with any arbitrary app. Because that's what an input method is: an arbitrary app that just happens to receive events through a different channel. – Ken Thomases Sep 06 '14 at 09:34
  • That and the cocoa input method API pretty much relies on the cocoa text system for multiple stage input with the concept of marked ranges of text. – uchuugaka Sep 06 '14 at 10:27
  • Well, that part the question got right. Anything which implements `NSTextInputClient` is a "text view" as far as Cocoa is concerned, even custom classes having nothing to do with `NSText` or `NSTextView`. I've done it before. – Ken Thomases Sep 06 '14 at 11:24
  • @uchuugaka Do you know if the Japanese input method pictured in your answer using a public API for its input method selection window? I'm attempting to use `IMKCandidates` to construct something similar, but not seeing (for example) options for the rounded corners or ability to hide the numbers on the left. – pkamb Dec 24 '15 at 00:17
  • Part of the original post and @KenThomases comments, it most certainly uses a lot of public API to create its UI, but not necessarily wrapped up in one that is available to you. It also likely uses some private APIs if it needs to. (If there's a use-case, file a bug with Apple's developer site requesting API like that.) Part of the issue is, each language, and each approach to input can be entirely unique. The gist of it is, if you need to write an input method, you kind of already should know what you need and want that user experience to be. (barring acceptance testing feedback) – uchuugaka Dec 24 '15 at 03:42
  • In short, you should approach the design as if you may need to write the UI yourself. Start with a concept written out and any illustrations/diagrams to help visualize the experience and flow. Then revisit the API provided. It should still provide plenty of hooks to build out your own UI customizations. That often may include some replacement/conversion candidate window & UI that makes sense for the kinds of options provided to the user of that input method, generally language-specific. Consider a Telegraph system as a basic example of something that might be unique. – uchuugaka Dec 24 '15 at 03:47