From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 30 Oct 2007 10:39:57 +0900 From: underspecified To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] unicode input for OSX-native drawterm In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2971_25575241.1193708397915" References: <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com> Cc: inferno-list@vitanuova.com, acme-sac@googlegroups.com Topicbox-Message-UUID: de614806-ead2-11e9-9d60-3106f5b1d025 ------=_Part_2971_25575241.1193708397915 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I apologize for being grumpy in my last post. While we are talking about Unicode input in OS X, I feel I should put in my 2 cents' worth. In Carbon, input events (from the keyboard, IMEs, character maps, etc.) generate Unicode text input events. If the Unicode events are not handled by your app, then raw keyboard events are generated. What our apps really need is to handle Unicode text events. That will make it possible for Bulgarian keyboards, Japanese IMEs, and math symbols from the special chars table to work in drawterm, emu, what-have-you-not. I've already implemented handlers for Unicode input events in Acme SAC for OS X. Grabbing the Unicode chars from kEventRawKeyDown might work for Bulgarian, but it doesn't scale. The problem with doing everything in Unicode is that we need to redo all of our special character checks and conversion to use Unicode values instead of MacCharCodes. I've been working on Unicode-based special character handling as well, but the code is still a bit buggy. With the release of Leopard, it looks like Apple is finally phasing out Carbon. It has been brought up a couple of times on various lists, but the future of p9/inferno apps on OS X is ideally a Cocoa rewrite. This would actually take care of a lot of the annoying aspects of internationalized text input for us. I wish I had the time and Objective C knowledge to undertake such a project. Anyway, could I propose an osx-ip9 Google group or mailing list, so that all of us Mac hackers working on different apps can keep current on what others are working on? --underspecified On 10/30/07, underspecified wrote: > > *sigh* I don't need to complain, but this is *exactly* what I have been > working on in Acme SAC for the last month. > We *really* need some way of getting the drawterm/emu/acme-sac OS X code > in sync... > > --underspecified > > On 10/30/07, andrey mirtchovski wrote: > > > > this is the last piece of the puzzle that i was missing from the OSX > > drawterm: the ability to input text when i'm using a different > > keyboard layout than the english one (that's bulgarian for me). > > > > this file will pick up the unicode key from the input event and send > > it directly to plan9 without attempting to pass it as a char (which is > > what the old code did). > > > > since my screen.c has accumulated quite a few patches missing from the > > CVS repository i'm attaching the whole thing. maintainers of acme-sac > > and inferno can add the changes: they're in the kEventRawKeyDown event > > handler and the convert_key routine and are quite obvious. > > > > > ------=_Part_2971_25575241.1193708397915 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I apologize for being grumpy in my last post.

While we are talking about Unicode input in OS X, I feel I should put in my 2 cents' worth.
In Carbon, input events (from the keyboard, IMEs, character maps, etc.) generate Unicode text input events.
If the Unicode events are not handled by your app, then raw keyboard events are generated.
What our apps really need is to handle Unicode text events. That will make it possible for Bulgarian keyboards,
Japanese IMEs, and math symbols from the special chars table to work in drawterm, emu, what-have-you-not.
I've already implemented handlers for Unicode input events in Acme SAC for OS X.

Grabbing the Unicode chars from kEventRawKeyDown might work for Bulgarian, but it doesn't scale.
The problem with doing everything in Unicode is that we need to redo all of our special character checks and
conversion to use Unicode values instead of MacCharCodes. I've been working on Unicode-based special
character handling as well, but the code is still a bit buggy.

With the release of Leopard, it looks like Apple is finally phasing out Carbon. It has been brought up a couple
of times on various lists, but the future of p9/inferno apps on OS X is ideally a Cocoa rewrite. This would actually
take care of a lot of the annoying aspects of internationalized text input for us. I wish I had the time and Objective
C knowledge to undertake such a project.

Anyway, could I propose an osx-ip9 Google group or mailing list, so that all of us Mac hackers working on different
apps can keep current on what others are working on?

--underspecified

On 10/30/07, underspecified <underspecified@gmail.com> wrote:
*sigh* I don't need to complain, but this is *exactly* what I have been working on in Acme SAC for the last month.
We *really* need some way of getting the drawterm/emu/acme-sac OS X code in sync...

--underspecified


On 10/30/07, andrey mirtchovski < mirtchovski@gmail.com> wrote:
this is the last piece of the puzzle that i was missing from the OSX
drawterm: the ability to input text when i'm using a different
keyboard layout than the english one (that's bulgarian for me).

this file will pick up the unicode key from the input event and send
it directly to plan9 without attempting to pass it as a char (which is
what the old code did).

since my screen.c has accumulated quite a few patches missing from the
CVS repository i'm attaching the whole thing. maintainers of acme-sac
and inferno can add the changes: they're in the kEventRawKeyDown event
handler and the convert_key routine and are quite obvious.



------=_Part_2971_25575241.1193708397915--