From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 30 Oct 2007 10:20:01 +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: <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2939_4447029.1193707202013" References: <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com> Cc: inferno-list@vitanuova.com, acme-sac@googlegroups.com Topicbox-Message-UUID: de5ae60a-ead2-11e9-9d60-3106f5b1d025 ------=_Part_2939_4447029.1193707202013 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline *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_2939_4447029.1193707202013 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline *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_2939_4447029.1193707202013-- 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-- 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. > > > > > > > > > > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <56a297000710300142h6962b777l2d53ae7b95d407a0@mail.gmail.com> Date: Tue, 30 Oct 2007 17:42:21 +0900 From: "Noah Evans" 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: <8ccc8ba40710300107k77ea48c4g4deaeb4938dea1bb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com> <8ccc8ba40710300107k77ea48c4g4deaeb4938dea1bb@mail.gmail.com> Topicbox-Message-UUID: dee37880-ead2-11e9-9d60-3106f5b1d025 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 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 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. > > > > > > > > > > > > > > > > > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <56a297000710300142h6962b777l2d53ae7b95d407a0@mail.gmail.com> References: <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com> <8ccc8ba40710300107k77ea48c4g4deaeb4938dea1bb@mail.gmail.com> <56a297000710300142h6962b777l2d53ae7b95d407a0@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D273B2B-22D7-4AFF-A7C7-E94B17A4E6D2@telus.net> Content-Transfer-Encoding: 7bit From: Paul Lalonde Subject: Re: [9fans] unicode input for OSX-native drawterm Date: Sat, 3 Nov 2007 08:14:28 -0700 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Topicbox-Message-UUID: e80d2ffa-ead2-11e9-9d60-3106f5b1d025 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Sorry to come in late, I've been on the road all week) One thing about doing this Cocoa port --- I've been reflecting on this since Leopard was announced as dropping Carbon --- is that we should probably take the opportunity to build the front-end, simple as it is, using the recommended gui tool chain. It doesn't uglify the distribution build process, and lets us address (by doing nothing more) most of the bugs I put in when I did the Carbon port. Our needs are simple: we just post one image, appropriately resized, in one window. The code interface requires an objective-C to C++ wrapper to hand back that image for writing and its converse, mouse event & keyboard communication (trivial) and probably a short function to handle the resize event. It should be substantially simpler than the twisted little maze of Carbon calls. Paul On 30-Oct-07, at 1:42 AM, Noah Evans wrote: > 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 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 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. >>>>> >>>>> >>>> >>>> >>> >>> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHLJBUpJeHo/Fbu1wRAn/6AJ4uu10HJpAYIIjHcyMiVgqy8Y8UigCgkV2p 5lwQVdlSwstuN9W+feB/SzQ= =FwxW -----END PGP SIGNATURE----- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60711030823p332b338ah2f8896ceab054204@mail.gmail.com> Date: Sat, 3 Nov 2007 08:23:52 -0700 From: "David Leimbach" 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: <5D273B2B-22D7-4AFF-A7C7-E94B17A4E6D2@telus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com> <8ccc8ba40710300107k77ea48c4g4deaeb4938dea1bb@mail.gmail.com> <56a297000710300142h6962b777l2d53ae7b95d407a0@mail.gmail.com> <5D273B2B-22D7-4AFF-A7C7-E94B17A4E6D2@telus.net> Topicbox-Message-UUID: e81431ce-ead2-11e9-9d60-3106f5b1d025 Carbon is still in Leopard. Just built the latest native drawterm using it like 5 minutes ago. On Nov 3, 2007 8:14 AM, Paul Lalonde wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > (Sorry to come in late, I've been on the road all week) > > One thing about doing this Cocoa port --- I've been reflecting on > this since Leopard was announced as dropping Carbon --- is that we > should probably take the opportunity to build the front-end, simple > as it is, using the recommended gui tool chain. It doesn't uglify > the distribution build process, and lets us address (by doing nothing > more) most of the bugs I put in when I did the Carbon port. Our > needs are simple: we just post one image, appropriately resized, in > one window. The code interface requires an objective-C to C++ > wrapper to hand back that image for writing and its converse, mouse > event & keyboard communication (trivial) and probably a short > function to handle the resize event. It should be substantially > simpler than the twisted little maze of Carbon calls. > > Paul > > > On 30-Oct-07, at 1:42 AM, Noah Evans wrote: > > > 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 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 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. > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFHLJBUpJeHo/Fbu1wRAn/6AJ4uu10HJpAYIIjHcyMiVgqy8Y8UigCgkV2p > 5lwQVdlSwstuN9W+feB/SzQ= > =FwxW > -----END PGP SIGNATURE----- > From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <326364c20711031150m63a0bee9lb9ba40aaf6f5289e@mail.gmail.com> Date: Sat, 3 Nov 2007 14:50:00 -0400 From: "Tom Lieber" 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: <3e1162e60711030823p332b338ah2f8896ceab054204@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com> <8ccc8ba40710300107k77ea48c4g4deaeb4938dea1bb@mail.gmail.com> <56a297000710300142h6962b777l2d53ae7b95d407a0@mail.gmail.com> <5D273B2B-22D7-4AFF-A7C7-E94B17A4E6D2@telus.net> <3e1162e60711030823p332b338ah2f8896ceab054204@mail.gmail.com> Topicbox-Message-UUID: e84293ac-ead2-11e9-9d60-3106f5b1d025 On 11/3/07, David Leimbach wrote: > Carbon is still in Leopard. Just built the latest native drawterm > using it like 5 minutes ago. Yes, it's just that its days have been numbered by Apple. -- Tom Lieber http://AllTom.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <326364c20711031150m63a0bee9lb9ba40aaf6f5289e@mail.gmail.com> References: <14ec7b180710291805w79dbfa72p815d72b7a0d5f134@mail.gmail.com> <8ccc8ba40710300107k77ea48c4g4deaeb4938dea1bb@mail.gmail.com> <56a297000710300142h6962b777l2d53ae7b95d407a0@mail.gmail.com> <5D273B2B-22D7-4AFF-A7C7-E94B17A4E6D2@telus.net> <3e1162e60711030823p332b338ah2f8896ceab054204@mail.gmail.com> <326364c20711031150m63a0bee9lb9ba40aaf6f5289e@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jeff Sickel Subject: Re: [9fans] unicode input for OSX-native drawterm Date: Sun, 4 Nov 2007 01:24:42 -0600 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Topicbox-Message-UUID: e88482bc-ead2-11e9-9d60-3106f5b1d025 On Nov 3, 2007, at 1:50 PM, Tom Lieber wrote: > On 11/3/07, David Leimbach wrote: >> Carbon is still in Leopard. Just built the latest native drawterm >> using it like 5 minutes ago. > > Yes, it's just that its days have been numbered by Apple. and like old OS 9, it's dead.. no longer being supported or going anywhere. That said, we're lucky that the current drawterm code in Carbon behaves properly: Apple does not support any GUI code or event loops from Cocoa or Carbon in anything other than the main thread--and the current Carbon port is a direct reflection of the X11 ports, which let child threads create their own event loops to handle drawing: a direct conflict w/ the current supported architecture for Carbon or Cocoa. I'd like to see a Cocoa front end that is launched as a separate process. Sure you take a bit of a hit on the pass-thru, but you can then let the Cocoa event loop do it's odd things on top of Mach and let drawterm and other code use the Plan 9 model. jas From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1c2955bd3c63bf0d0f7447696d35feba@terzarima.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] unicode input for OSX-native drawterm From: Charles Forsyth Date: Sun, 4 Nov 2007 10:54:39 +0000 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: e88dd86c-ead2-11e9-9d60-3106f5b1d025 > Apple does not support any GUI code or event loops > from Cocoa or Carbon in anything other than the main thread--and the some people just never learn. i think they should stick to consumer gadgets.