Re: [9fans] unicode input for OSX-native drawterm

Re: [9fans] unicode input for OSX-native drawterm

[underspecified]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1269 bytes --]

Re: [9fans] unicode input for OSX-native drawterm

[underspecified]

[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3454 bytes --]

Re: [9fans] unicode input for OSX-native drawterm

[Francisco J Ballesteros]

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

Re: [9fans] unicode input for OSX-native drawterm

[Noah Evans]

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

Re: [9fans] unicode input for OSX-native drawterm

[Paul Lalonde]

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHLJBUpJeHo/Fbu1wRAn/6AJ4uu10HJpAYIIjHcyMiVgqy8Y8UigCgkV2p
5lwQVdlSwstuN9W+feB/SzQ=
=FwxW
-----END PGP SIGNATURE-----

Re: [9fans] unicode input for OSX-native drawterm

[David Leimbach]

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 <plalonde@telus.net> 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 <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.
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFHLJBUpJeHo/Fbu1wRAn/6AJ4uu10HJpAYIIjHcyMiVgqy8Y8UigCgkV2p
> 5lwQVdlSwstuN9W+feB/SzQ=
> =FwxW
> -----END PGP SIGNATURE-----
>

Re: [9fans] unicode input for OSX-native drawterm

[Tom Lieber]

On 11/3/07, David Leimbach <leimy2k@gmail.com> 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/

Re: [9fans] unicode input for OSX-native drawterm

[Jeff Sickel]

On Nov 3, 2007, at 1:50 PM, Tom Lieber wrote:

> On 11/3/07, David Leimbach <leimy2k@gmail.com> 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

Re: [9fans] unicode input for OSX-native drawterm

[Charles Forsyth]

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