Kaixo! On Thu, Aug 07, 2003 at 09:51:36PM +0700, Ivan Pascal wrote:
>> Well, I used to like that behaviour of "typewriter capslock" (with shift
>> key removing the caps lock, and the capslock affecting all keys and
>> being a shift lock in fact)
>
> Unfortunately I can't imagine how to make such mode ("affects all keys" but
> "Shift cancels Caps" ) in XKB.
Well, I described how it worked on mechanical typewriters; just having
a ShiftLock is enough. (OTOH it is a long time since I last used
a mechanical typewriter, and since I discovered the CapsLock on
computers (allowing to have uppercase of ccedilla for example), I like
this better. On typewritters the "Shift Lock" was useful to type
lots of numbers (on French and Belgian keyboars, digits are on second
shift position); but on computers there is the numeric keyopad...)
> > - when "idotless" is paired with "I", then "I" is used as the uppercase;
> > otherwise CapsLock has no effect on that letter and the lowercase
> > "idotless" is returned.
>
> Probably ConvertCase procedure doesn't know how to convert it to uppercase.
Where is the list of internal case pairs ?
> > the lowercase (the letters may be different, eg: [ x, A ] will
> > work.
>
> Right. As I said xkbcomp just wants the first symbol be lowercase and the
> second one be uppercase to consider the key as alphabetic.
Yes, and a very wise design, it allows a solution for "special uppercasing"
(there is the Turkish "i", but also the "eng" and "schwa/turned e" (there
exists two variants for the uppercase for both letters); and maybe others)
> > So it seems the problem is indeed solved; but the behaviour (a quite good
> > one in fact) is different of what you and I thought it was.
>
> Yes. Thank you for your experiments.
>
> I wrote a test program that prints keysyms for all keys in a map for all
> combinations of Lock and Shift. And than I ran it for all layouts in both
> modes and compared the results.
> There are few differences (in 'tr' for example) and in all cases caps:shift
> produces more reasonable result.
Could I get that program somewhere?
I didn't noticed any difference at all in my experiments; and I would
like to know what those differences are...
> There is one only exeption in 'ca' and 'ca_enhanced' maps:
> the key [ eth, Dstroke ]. It's recognized as alphabetical one
IMHO that is clearly a bug, it should be [ eth, ETH ]
(or [ eth, dstroke ]). Probably introduced by someone not aware of
the character difference between ETH and Dstroke, and basing the keyboard
map only in visual appareance).
So, if that is the only reason not to make "caps:shift" the default, then
it may be dismissed. (and the Canadian keyboard map should be fixed to
have either [ eth, ETH ] or [ eth, dstroke ] )
> (lowercase - uppercase letters) and the results are different.
> Lock with caps:internal gives ETH
> but with caps:shift it gives Dstroke (and there is not way to get ETH).
Mmmh; I don't see any difference in behaviour at all between caps:shift
and caps:internal !
But I see a difference between old (in ..../xkb/ ) and new (in .../xkb/pc/ )
keymaps.
Old ones behave as in your description of caps:internal; new ones
behaves as in your description of caps:shift
I tested with [ a, Greek_OMEGA ], when the keyboard is listed as old
one; then CapsLock gives "A"; when it is listed as new layout, then
CapsLock gives "Greek_OMEGA".
(So, the solution for the Turkish keyboard problems would be to use
only new layout ones; it solves my problem, but I wonder how I don't
see any difference when using -option "caps:shift" or -option "caps:internal")
> Also there is a problem with new 'one group' keymaps that appeared in 4.3.0.
> In such keymap there are many four-level keys. The problem is that
> third and fourth levels in some cases is an alphabetic pair but in some other
> is not, therefore they should be processed differently for different kinds of
> four-level keys.
> But I made only one 'alphabetic' rule for all such keys and
> too simplified procedure for recognizing them as alphabetic (it checks
> only two first levels and ignores others).
Yes; each pair of unshifted/shifted symboles should be treated separately
(there may be [ less, greater, ae, AE ], as well as [ q, Q, at, micron ],
and [ o, O, oe, OE ] )
> Now I see that I have to improve such keys processing. But when it be done
> I think we can make caps:shift mode the default.
Yes.
(I still wonder why I don't see any difference between caps:shift and
caps:internal; nor why old and new layouts act differently...)
--
Ki �a vos v�ye b�n,
Pablo Saratxaga
http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466
[you can write me in Walloon, Spanish, French, English, Italian or Portuguese]
pgp00000.pgp
Description: PGP signature
