Re: Combined Yorùbá characters with dot below and tonal diacritics

[Philippe Verdy]

2015-04-12 11:27 GMT+02:00 Ilya Zakharevich <nospam-abuse at ilyaz.org>:

> > Note also that (since always), MSKLC generated drivers have never allowed
> > us to change the mapping of scancodes (from hardware keyboards) to
> virtual
> > keys, aka "vkeys", or to "WM_SYSKEY" (this is hardwired in a lower
> internal
> > level).
>
> Wrong.  Look for any French or German keyboard.
>

Wrong. I use a French keyboard everyday. And even used MSKLC for extending
this French keyboard (but now with weird compatibility problems in Windows
Server 2012 and Windows 8+, this is a separate issue).

Seriously, how can you imagine that I never looked at a French keyboard ?

You're still speaking about something else, I just spoke about MSKLC which
has not been revized at all to generate compatible drivers. But even if it
did, it DOES NOT support the extended interface in "kdh.h" (which is NOT
the ".klc" format that MSKLC supports)

And yes, MSKLC *does not* allow changing the mapping of scancodes (from
hardware keyboards) to vkeys, it just allows editing the mapping from
sequences of vkeys(+limited keyboard states) to ONE and only ONE code
point. the first part is not accessible (and not described at all in .klc
source files which have nothing in common to the internal binary structures
generated in installable keyboard drivers, and used then by the kernel) and
it offers absolutely no way to describe a layout geometry (as needed for
touch interfaces) where we can reposition the vkeys accurately (for example
for typing with left-hand only, or for an ABCD disposition, or for defining
other custom input methods similar to phones using 10 digits or using
predictive "T9" methods, or for creating specific selection grid layouts
for symbols and emojis with mutliple selectable sets):

MSKLC still assumes legacy 101/102 key geometries (and does not in fact
distinguish the numeric keypad, with the *only* exception of the decimal
separator key which is distinguished). And there's no way to change the
layout of "function keys" (those keys that are show with a black/dark grey
background in this editor): you can only defined mappings for the vkeys in
the alphanumeric part plus the spacebar. Everything else is assumed
(there's also no distinction of the two Alt keys for keymaps that want to
distinguish Ctrl+LeftAlt and Ctrl+AltGr which may also be Shifted)

In fact the *.klc source file format (specific to the MSKLC tool) is not
even documented (and not supported at all by "klc.h" which just describes
the binary structures: the kernel has abosutely no support for processing
.klc files directly, it just wants the binary-encoded tables exposed by the
driver that must be compiled).

And did I say that the MSKLC tool does not even worok in Windows 8+ or
Windows Server 2012 +? It cannot compile the driver (fails to launch the
linker of the Windows SDK, even if it's correctly installed). To run this
tool you still need to use it in previous versions of Windows. The
generated driver however is installable in later versions of Windows (with
some quirks to coexist with the onscreen interface).

And even in Windows 8 and Windows Server 1012 here are TWO distinct touch
interfaces:
- one compatible with accessibility options tools (works even without a
touch screen, you can click on it with your mouse, or touch it),
- another newer one specific for touch screens (not available without a
touch screen, but when it exists, its really behaves differently but with
too frequent bugs if you use it simultaneously with a physical keyboard,
notably each time you have used it to touch the onscreen shift keys, whose
state is incorrectly defined; the only way to solve these bugs in Windows 8
is to disable the touch screen device completely, but it is enabled
autiomatically...).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20150412/334f8dae/attachment.html>