9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Noah Evans" <noah.evans@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] unicode input for OSX-native drawterm
Date: Tue, 30 Oct 2007 17:42:21 +0900	[thread overview]
Message-ID: <56a297000710300142h6962b777l2d53ae7b95d407a0@mail.gmail.com> (raw)
In-Reply-To: <8ccc8ba40710300107k77ea48c4g4deaeb4938dea1bb@mail.gmail.com>

I messed around with cocoa and emu for a couple of hours a while back.
I can give a few pointers for anyone starting from stratch(or
implement it if there's a cocoa expert willing to help me). The
primary problem was setting up the runtime manually(os x cocoa
applications do a lot of the work for you behind the scenes, win.c's
way of doing things doesn't work that way so you have to do it
yourself).

I'm really enjoying how many people are working on OS X these days.
Acme-sac for OSX especially.

Noah

On 10/30/07, Francisco J Ballesteros <nemo@lsub.org> wrote:
> 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 <underspecified@gmail.com> 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 <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.
> > > >
> > > >
> > >
> > >
> >
> >
>


  reply	other threads:[~2007-10-30  8:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com>
2007-10-30  1:20 ` underspecified
2007-10-30  1:39   ` underspecified
2007-10-30  8:07     ` Francisco J Ballesteros
2007-10-30  8:42       ` Noah Evans [this message]
2007-11-03 15:14         ` Paul Lalonde
2007-11-03 15:23           ` David Leimbach
2007-11-03 18:50             ` Tom Lieber
2007-11-04  7:24               ` Jeff Sickel
2007-11-04 10:54                 ` Charles Forsyth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56a297000710300142h6962b777l2d53ae7b95d407a0@mail.gmail.com \
    --to=noah.evans@gmail.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).