Hi Cameron,
Cameron McCormack wrote:
Hi Doug.
Doug Schepers:
Further, when a QWERTY keyboard is remapped to a Dvorak layout, but the
labels on the keys remain unchanged, a typist would expect that hitting
the key labeled "Q" would result in an apostrophe... they would expect
the same behavior if they had bothered switching the keycaps, as well as
remapping. If they were asked to type "Q" or "q", they would naturally
hit the key that, on my keyboard, is labeled "X". The same goes for any
remapping, such as when an US keyboard is repurposed to some other
alphabet.
Of course, but there is already wording in that algorithm to take the
keyboard layout mapping into account.
We've already determined that we can not and should not identify a key
by keyboard layout, i.e. the physical position of the keys; the same
applies to what is printed on the keycap, even more so.
It’s not what is printed on the keycap that is important, but the
function of the key subject to the keyboard layout mapping.
But we are trying to identify a single key, and not what functions it
may have under different modifiers, yes?
Out of interest, how does the algorithm take that into account.
for my default layout the keystrokes that normally produce q|Q produce
ŋ|Ŋ inɛtead, and i need to type AltGr+q/AltGr+Q to get q|Q
my system input local is en-AU, keyboard driver is customised to
specific African languages, and physical keyboard is standard qwerty.
I'm curious how the algorithm will handle undefined input locales, or
keyboard drivers that are forced to use the wrong input locale (which in
theory is most of the languages in the world at the moment).
As far as i can see there is no way for an application to know what
keystrokes are being used and extrapolate what character was intended
from the sequence, esp. if more sophisticated processing and reordering
is occurring within a driver before the character is past to an application.
At best you might be able to determine what keystrokes are used (maybe
not always) and what characters are ultimately generated, although
characters generated may not be in the same order as keystrokes that
generate those characters.
--
Andrew Cunningham
Vicnet Research and Development Coordinator
State Library of Victoria
328 Swanston Street
Melbourne VIC 3000
Ph: +61-3-8664-7430
Fax: +61-3-9639-2175
Email: [EMAIL PROTECTED]
Alt email: [EMAIL PROTECTED]
http://home.vicnet.net.au/~andrewc/
http://www.openroad.net.au
http://www.vicnet.net.au
http://www.slv.vic.gov.au
begin:vcard
fn:Andrew Cunningham
n:Cunningham;Andrew
org:State Library of Victoria;Vicnet
adr:;;328 Swanston Street;Melbourne;VIC;3000;Australia
email;internet:[EMAIL PROTECTED]
title:Research and Development Coordinator
tel;work:+61-3-8664-7430
tel;fax:+61-3-9639-2175
tel;cell:0421-450-816
x-mozilla-html:FALSE
url:http://www.openroad.net.au/
version:2.1
end:vcard
