Grzegorz Prokopski <[EMAIL PROTECTED]> writes:
> Hi!
>
> I am trying to make dosemu's keyboard more Polish-friendly.
> I downloaded and applyied keyboard path for dosemu 1.0.0
> (dosemu-1.0.0.eb1.21.patchset.tar.gz)
> and tryied some folks under text console.
>
> Looking at keymaps.c i saw "pl" keyboard. That looked good, but
> ocurred to be unusable for me. "auto" option worked a bit better for
> me, as it gave me *some* code for *almost* every of my national char's
> (but not the right codes - anyway).
O.k. things are better then they look at first glance.
With dosemu-1.0.0.eb1.21.patchset.tar.gz all of the needed
infrastructure is in place. It hasn't been taken much advantage
of yet however.
>
> There are 3 maps.
> normal - key_map
> upper - shift_map
> alt (right) - alt_map
Thre is also a shift + alt keymap.
Because previous to my patchset the infrastructure was not
in place to do more nothing has yet taken advantage of it.
You get to be first :)
Currently only the de & us keymaps are have been fully converted.
In particular that means you will not see the 0xef combinations
in either keymap. What you will see is a the unicode values,
of the keys you want. This is the prefered way to handled things
now allowing you to have keymaps independant of character set encoding.
>
> But in my language I have for example letter "a" and "A"
> both with "," at the bottom (as if You joined these two characters into
> one).
> Codes I would like to have for them (for the program that I run
> inside dosemu - 8bit codes) are:
> "a" - 97 (60h) - world standard
> "A" - 65 (41h) - world standard
> "a," - 134 (86h) - local standard called Mazovia or Latin2
> "A," - 143 (8fh) - same as above
>
> So I have at least 4 cases when "a" key is pressed
> - no alt, no shift - just "a"
> - no alt but shift - just "A"
> - alt, no shift - "a,"
> - alt and shift - "A,"
>
> Add to it, that when CapsLock is pressed it should behave as if it
> had Shift pressed... Is it possible to do such things that I need
> with those (only) 3 maps ?
Not with those three. But that is how caps lock is currently
implemented. If a key has a letter character use the shift
variation.
> (Where's the code, that uses them ? in old_serv_xlat.c ??? is it
> used anyway? so why is it called "old"? if it isn't used why
> is it in source tree ?)
The translation code is in serv_xlate.c old_ser_xlat.c is the
implementation before the rewrite. The are both present to make
it simple to test for regression and bugs by just compiling the
code differently.
> Uppercasing is also a problem, 'cause its not as simple as -32 for
> "normal" chars - it must be given as a table for every single char.
If just using the shift table is suffient then we are good here.
>
> Ive got 3 standards of coding for polish chars in front of me:
> - Mazovia (Latin2) - doesn't broke the frames and IS the standard
For this one I need a translation table to unicode in
src/base/translate.c ( I don't have a reference for it.)
> - DOS 852 codepage (don't like it too much)
> - Windows 1250 (shit!)
>
> Anyway it doesn't really matter which of them I code in dosemu.
> I can use any of them, cause my database program can change the codes
> from input using recode table to internally used Mazovia (Latin2)
> and then recode again using different table before displaying.
> But it would be nice to have some standard kept.
Unless they actual keyboard layout is different you can do them
all with one keymap.
A usefull place to know about is src/base/translate/keysym_approximations.c
This has a table of approximations to use when the appriate unicode
character isn't in a character set.
>
> So my question is: how to ? Is it possible to have it done using
> today's dosemu internals, or should I change sth significantly ?
> If yes - where to look, what to change ?
> Would You tell me more about those 3 recode tables ?
> I understand that they have 0xef?? format, where ?? is sth,
> that really matters. But how it really works - especially for
> alt_map ? (maybe add alt_shift_map to defs, or to uppercase method ?
> and small change to recode proc - btw: where it is done ?)
shift_alt_map has already been added :)
See down at the bottom in the auto case.
Ignore the 0xef?? case, it is a backwards compatibility hack,
(I have taken part of the user defined range of unicode
and said it maps directly to whatever characters set you are using).
Much better is to actually use the unicode character you want.
Since I don't know for certain which character set the existing keymaps
were designed for, figuring out the appropriate character is difficult
and hasn't been done, except for the use & de keymaps.
>
>
> The second idea is that *IF* dosemu gives proper scancodes (those
> twice 8bit) I would be able to use a program that changes scancodes
> to the codes I need - as I used to use such in real DOS.
> Would it work anyway? I tryied to use it under 0.96 dosemu and it
> didn't work.
Yes it will bug only in X with the keycode options & on the console
with the raw keyboard option.
It will also give you the correct scancodces via telnet etc. But only
if you have an appropriate map for dosemu to work backwards with.
>
> Last thought: I think I should be able to change what char is displayed
> on the console (via ssh or telnet to be exact) as chat that has code XX
> ?
> It isn't dosemu-related ;) Where to change such things ?
> I would like to have normal, 8bit frames, instead of strange
> -|+{} chars when using dosemu via ssh
This in part controlled by what external chracter set you tell dosemu you have.
But it is further complicated by what the current slang code for displaying
characters can do.
Currently dosemu cannot handle that unless you tell dosemu you terminal
is running a character set encodeing that has those chracters &
you actuallly configure you terminal to use that character set.
As iso8859-2 is most likely what your terminal is running this becomes
nontrivial.
Doing this better is on the todo for dosemu but it will require a
rewrite of how we display chracters on the terminal, and so is coming
along slowly.
>
> Whoa! I wrote a lognish letter... Sorry ;)
> Waiting four Your words.
I hope this helps. I am certain this doesn't tell you everything,
but hopefully this points you in the right direction.
Oh, one other thing. As this keymap gets written. I have a regresion
test around for this kind of thing, and putting it in the regression
test so I can ensure further changes to the code will not break
your keyboard would be a real help.
Eric
