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----- >