Giulio Bernardi wrote:
>> > Last lines of the listing in this page show it:
>> > http://developer.apple.com/qa/qa2005/qa1446.html
>> >  > However, instead of doing all this stuff, we can receive the
>> unicode character asking for kEventParamKeyUnicodes parameter in
>> kEventRawKeyDown/Repeat/Up event, and the "ascii" one asking for
>> kEventParamKeyMacCharCodes parameter.
> 
>> The unicode char is useless for reporting the VKey in up/down events.
>> It gets messy when chars can be made by more than one key, or are
>> composed. Been there, tried that and it didn't work.
> 
> Well, ok, I just used it for very few keys like alphabet, number, space
> and so on, since we can't find an exact mac keycode to translate to VK_A
> and friends.

In that case, OK. I won't call A..Z an unicode char :)


>> > But here we have a problem: the Virtual Key Code is too low level,
>> the character is too high level since we can't intercept arrows,
>> function keys and so on.
>> > > But, it looks like some keys are constant across all keyboards (I
>> think it's because they are always in the same position on all
>> keyboards), and they are the "non visual" characters.
>>
>> I won't assume that.
> 
> Well, we have to other mean for keys like function keys, ins, del,
> arrows and so on. Moreover, i found some pieces of code around that do
> exactly this thing (use hardcoded values for these keys).
> See later for more infos.
> 
>> Hmm... I note the capslock key on that layout. I've read somewhere
>> that macs don't have a numlock. Is that still the case (I can't check,
>> since I hooked a pc keyboard to my mini)
> 
> 
> Well, my old adb keyboard has both numlock and caps lock. And, watching
> in Macintosh ToolBox Essentials pdf, even the old Apple Keyboard II (I
> think it's the one of the first Mac made ever :D) has them (even if it
> lacks the function keys: but, considering that my machine is the oldest
> one that can run os x and that newer mac use pc-like keyboards, I think
> we should not have problems with these keys)

IK, than I misread. Numlock shift and keypad are a bit special, since
they have 2 VKcodes


> However, trying to search for code examples, I found interesting things:
> It looks like a lot of people did what I did (try with known keycodes,
> then rely on the ascii/unicode char to find the key), while Apple itself
> did something very similar to what you did for gtk in the implementation
> of the X Window server that runs under Mac OS X :)

The reason is imo understandable. In most cases you encountered (i
guess), the keycodes are only relevant inside the project. IE, the
user/programmer knows what key are needed eand what to do with it. So in
those cases you can have a simple approach.
X is more like us. X has to produce a constant set of keysyms for every
key pressed, unknown what a user/devel will do with those keysims.
The LCL is the same, we produce a VK and it is upto the devel what to do
with it.

> That is, they also use that list of hardcoded values (function keys,
> keypad and so on) to map to X11 keycodes, and for other values they try
> to get the char or unicode char for all keycodes. But they (as you did)
> initialize this map at startup: their list is 248 entries long for
> unicode keyboard layouts (I don't know where this number came from) and
> 128 entries for non unicode layouts. They try to get a char for every
> keycode, and then they try to find a X11 keycode for that char, and they
> save it to the map, and then they put in the map the known keycodes like
> funcion keys and so on.

Maps cost a little memory but are way faster in processing when an event
happens. In case of a map you only have to kookup and not search again.

> They call again this function when, during X event dispatching, they
> notice that keyboard layout has changed: I think that we can easily do
> the same in kEventRawKeyDown/Repeat/Up events by inspecting parameter
> kEventParamKeyboardType.

Changing layouts on the fly is imo a nice to have feature for post 1.0

> This file is here:
> http://webcvs.freedesktop.org/xorg/xc/programs/Xserver/hw/darwin/quartz/quartzKeyboard.c?revision=1.4&view=markup

Thanks for the link. SOme more reading :)

Marc

_________________________________________________________________
     To unsubscribe: mail [EMAIL PROTECTED] with
                "unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Reply via email to