[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] keyconf
- From: Elias Pschernig <elias.pschernig@xxxxxxxxxx>
- Date: Tue, 15 Mar 2005 23:48:42 +0100
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=LtihX7RtpDkdMGJAai8Oox59kQJk6QjmE2wcdEHU0TR67DBCUdRvELLTmOyHqP1D8J2to/Fk9Kto4XEn52m2TETgpWgoKaAfXoR8tTyQdhZsxYX1bBKFY/fInYOYJ+fnrUos5PcU6yC92Pv+TBn+T+d0fdywekjHgoXkec2f26s=
> So, if I understood correctly, wouldn't what you propose actually be a step
> backward ? It wouldn't work as well as now, and we would have to start from
> scratch anyway for the non-dinput driver...
>
Yes, it would be a regression. Currently, we do our own mapping in
pckeys.c, and that has dead-keys according to the various .cfg files.
The Right Way(TM) would be to have windows give us what symbol a key
should produce, without any .cfg files. But, as it is, DInput doesn't
provide that info complete, at least not AFAICS, it misses dead keys
support. So now, either we get a "proper" keyboard driver, with no
deadkeys, or the hackish pckeys.c thing which requires lots of .cfg
file which will never exactly match the real keyboard layout of
windows - but which support dead keys.
The non-dinput driver would return dead-keys. In fact, it would return
the exact same symbols for a keypress you get e.g. in Word. So that
would be perfect.