Kaixo!

On Wed, Aug 06, 2003 at 04:38:19PM +0700, Ivan Pascal wrote:

> > The name was misleading I thought it was the system where capslock
> > is similar to shift lock (how is that mode named then?) 
> 
> There is not such option now.  In my opinion it is inconvenient because such
> key affects all keys (including numpad) and can't be canceled with Shift key
> (the behaviour that usualy expected).  Nobody requested such option yet.

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)
 
> > And why isn't "caps:shift" made the default? It doesn't seem to change
> > anything for other layouts (after some quick tests).
> 
> Well.  When I two years ago suggested such behavior for CapsLock *you* argued
> against it. :-)

I misunderstood it; I tought it was a shiftlock...

> : But that behaviour won't be welcome in all cases, for example on French and
> : Balgian keyboards there is:
> :
> :    key <AE09> {        [        ccedilla,               9      ]

I tought that it meant that capslock will produce a "9" instead of
a "Ccedilla".

> 1) most of user will not notice any differences but
> 2) French or Belgian keyboard users will be surprised unpleasantly.

I tested it and it seems to work correctly with caps:shift
(setxkbdmap "fr" -options "caps:shift") ?
 
> > And what is exactly the difference between the caps:shift and the currently
> > default behaviour? 
> 
> In "caps:shift mode" if Lock modifier is set Xlib gets from keyboard map 
> a keysym from the second shift level the same as is chosen when Shift modifier
> is set.

?? You said that such behaviour is no more present.

> But since CapsLock key doesn't lock Shift modifier but Lock modifier
> it allows to distinguish cases "CapsLock is active" and "CapsLock is active and
> Shift key is pressed".  Also it allows only part of keys (alphabetical ones)
> be affected by CapsLock.

So, it is not the second shift level that is chosen; but
- if the second shift level is alphabetic, it is chosen;
- if not, the first shift level is uppercased.

is that right? 

In such case, trhe difference between caps:shift and caps:internal
will only be visible in keyboard layouts with alphabetic letters on
unshifted and shifted positions of a same key, but which are not different
cases of the same letters (that is the case of the Swiss keyboard, I'll
test with de_CH...

Mmh, the results are surprising; I see no difference at all between
caps:internal and caps:shift; maybe it is now the default?
in cas of a same key with different letters (I tested with "agrave" and
"otilde") the capslock gives uppercase of "Agrave", and with shift it gives
the uppercase of "Otilde".

The case of "i" with and without dots work well; some more tests show this:
- when i/Iabovedot are paired in a same key, Iabovedot is used as the uppercase
  of "i". Otherwise, "I" is used as the upepercase.
- 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. 

In fact the behaviour (with caps:internal or caps:shift, I see no difference
at all) seems to be this one (when capslock is active):

- if position shift 1 is a lowercase letter, and if shift2 is an uppercase
  letter; then the symbol in position shift2 is used as the uppercase value,
  and the symbol in shift1 as the lowercase value.
  that is, pressing the key gives the uppercase. pressing shift-key gives
  the lowercase (the letters may be different, eg: [ x, A ] will
  work.
- otherwise, for each alphabetic letter, the uppercase letter is returned;
  also for symbols in shift2 (eg: [ x, a ] gives "X" when you press
  the key, and "A" when pressed with shift).
- for non alphabetic letters, the symbol is returned as (CapsLock has
  no effect)

Tested with XFree86 4.3; I haven't tested with non latin alphabetic
letters that have upper/lower pairs (greek, cyrillic, armenian).

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.
  


-- 
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]

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to