From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8ccc8ba40710300107k77ea48c4g4deaeb4938dea1bb@mail.gmail.com> Date: Tue, 30 Oct 2007 09:07:22 +0100 From: "Francisco J Ballesteros" 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com> Topicbox-Message-UUID: ded84514-ead2-11e9-9d60-3106f5b1d025 THere's no much traffic on the list. using the inferno and/or 9fans lists to report what's being done to port emu/drawterm to macs would be nice. I guess I'll have to learn cocoa if I want to be able to adjust our inferno in the futue. On 10/30/07, underspecified wrote: > 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 < 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. > > > > > > > > > > > >