Re: CapsLock behaviour and Turkish keyboard
On Tue, 2003-08-05 at 14:32, Ivan Pascal wrote: > Owen Taylor wrote: > > On Tue, 2003-08-05 at 08:55, Ivan Pascal wrote: > > > Now Turkish keyboard users just have to set XkbOption "caps:shift". > > > With that option Xlib doesn't use 'internal capitalization' but CapsLock > > > key acts as 'locking Shift' (but can be canceled by Shift key). It solves > > > the problem. > > > > I don't think that this is a particularly good way to handling things. > > Using caps:shiftproduces all sorts of strange behavior - for example, > > the number keys will give their shifted variants. > > I risk to seem impolite but did you try this option before making such > assertion? If you tried you would notice that it is not true. I had the made the assumption that caps:shift did the classic X thing and changed the keysym to be Shift_Lock rather than Caps_Lock. With the actual mode of implementation (not using the Lock modifier), yes, you don't have the problem of it affecting non-alphabetic keys. However, you do have the problem that applications can't tell that the level change was produced by the caps-lock key. Which sometimes is useful information. For instance, the obvious fix for: http://bugzilla.gnome.org/show_bug.cgi?id=115384 which is to strip out the Lock modifier before checking for accelerator matches, won't work. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
On Wed, 2003-08-13 at 08:56, Ivan Pascal wrote: > > With the actual mode of implementation (not using the Lock modifier), > > yes, you don't have the problem of it affecting non-alphabetic keys. > > I would have the problem with "it affecting non-alphabetic keys" if I didn't > use the Lock modifier. There is not such problem because "the actual mode of > implementation" does use the Lock modifier. I tried to explain it in my > replies to Pablo. I think you just have to realize that XKB is too complex for anybody to fully understand it without spending several hours a week on it. :-) > > However, you do have the problem that applications can't tell that > > the level change was produced by the caps-lock key. Which sometimes > > is useful information. > > > > For instance, the obvious fix for: > > > > http://bugzilla.gnome.org/show_bug.cgi?id=115384 > > > > which is to strip out the Lock modifier before checking for accelerator > > matches, won't work. > > I am sorry for the repeating. > Did you try it before writing this? You really don't have to be rude. Just tell me to try it. I made the assumption that if I had read the relevant Xlib XKB code and read the relevant rules file, I would have some idea what was going on. A dangerous assumption when XKB is involved. Going back and rereading your mail and rereading the code, I see how it's being accomplished via the magic of consumed modifiers. But really, I don't feel bad about not figuring that out the first time. And I don't feel bad about not doing a bunch of practical experimentation. Life's too short. Too many other bugs to worry about. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
Owen Taylor wrote: > On Tue, 2003-08-05 at 08:55, Ivan Pascal wrote: > > Now Turkish keyboard users just have to set XkbOption "caps:shift". > > With that option Xlib doesn't use 'internal capitalization' but CapsLock > > key acts as 'locking Shift' (but can be canceled by Shift key). It solves > > the problem. > > I don't think that this is a particularly good way to handling things. > Using caps:shiftproduces all sorts of strange behavior - for example, > the number keys will give their shifted variants. I risk to seem impolite but did you try this option before making such assertion? If you tried you would notice that it is not true. > The Turkish user might well wonder why everybody else gets a useful > caps lock key, while they have this monstrosity. Do you have real complains from Turkish users? The solution I offered was tested by Deniz Akkus Kanca and Nilgц╪n Belma Bugц╪ner (an author of 'tr' keymap). They didn't notice any monstrosity and accepted this solution. I want to assure you it works as expected. CapsLock affects alphabetic keys only. XKB automaticaly recognizes what keys are 'letter' ones. Shift key being pressed cancels CapsLock action. What is wrong? > It should be possible in Xlib's code for handling > lock == Caps_Lock to simply special case this; if the lower case > key is 'i', then check to see whether the key in the second level > is 'I' or 'Idotabove', and act accordingly. Of course, you may add a 'specila case' kludge to Xlib. But the problem you want to solve doesn't exist actually. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
Owen Taylor wrote: > On Tue, 2003-08-05 at 14:32, Ivan Pascal wrote: ... > > I risk to seem impolite but did you try this option before making such > > assertion? If you tried you would notice that it is not true. > > I had the made the assumption that caps:shift did the classic X thing > and changed the keysym to be Shift_Lock rather than Caps_Lock. I agree, it is a bit confusing. The thing is that Turkish users described the problem as "CapsLock and Shift lead to different results". And I thought that "Caps acts like Shift" is a right description for the new mode. When I cut it to just "caps:shift" I meant that only. > With the actual mode of implementation (not using the Lock modifier), > yes, you don't have the problem of it affecting non-alphabetic keys. I would have the problem with "it affecting non-alphabetic keys" if I didn't use the Lock modifier. There is not such problem because "the actual mode of implementation" does use the Lock modifier. I tried to explain it in my replies to Pablo. > However, you do have the problem that applications can't tell that > the level change was produced by the caps-lock key. Which sometimes > is useful information. > > For instance, the obvious fix for: > > http://bugzilla.gnome.org/show_bug.cgi?id=115384 > > which is to strip out the Lock modifier before checking for accelerator > matches, won't work. I am sorry for the repeating. Did you try it before writing this? -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
Hi,
> 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.
> I tested it and it seems to work correctly with caps:shift
> (setxkbdmap "fr" -options "caps:shift") ?
Yes, it works! And it's a big surprise to me.
Of course now I understand why it happens but I didn't guess until you wrote
about it. :-)
Let me explain.
1) Xlib converts a keycode to a keysym in two steps.
At the first step it chooses a cell in a keyboard map table according to
the state of modifiers and gets a keysym. And the second step is that if
Lock modifier is set Xlib tries to convert the keysym to uppercase one using
an internal table.
2) For the cell choosing it uses rules called 'key type'. Such rule describes
what modifiers should be taken in account and what combiantion of modifiers
match each shift level. (Note that the modifers can be not Shift only but also
Control, Alt, etc.).
Each key can have own type (refer to own rule) and if there are more than one
'xkb group' in a keybaord map the key can have different types for different
groups.
3) The first step subroutine can remove some modifiers ('consume' in XKB terms)
if they are used for the sell selection. Otherwise it would be imposible to
cancel temporary a Lock modifier action. Thus if we want the "Shift cancels
Caps" mode we have to specify in the type description that if Shift is pressed,
Lock modifier should be removed (or hidden) and the second step will leave the
keysym unchaged.
4) xkbcomp program itself tries recognize what key is alphabetic and what key
is not and assign them different types (rules). The algorithm is simple,
if the keysym in the first level is some lowercase letter and the keysym in
the second level is some uppercase one it is an alphabetic key (note: the
program doesn't check any matching between them). Otherwise xkbcomp thinks
it is a 'non-alphabetic key with two levels'.
Also one can explicitly specify the key type in a keyboard map.
Now we can understand the results of your experiments.
The key [ccedilla 9] was not recognized as an alphabetic key because the second
symbol isn't an uppercase letter.
On the other hand the rule for 'simple two level' keys is:
if Shift is set choose the second level, otherwise choose the first one.
But (what I didn't guess) the rule says nothing about the consuming of Lock
modifier. And if Lock is set the second step converts ccedilla to uppercase
Ccedilla. If Shift is also set the first step chooses '9' and the second step
does nothing.
Actually there is not a difference between the 'two level' type and the
'alphabetic' type in caps:internal mode except Lock+Shift case.
'Alphabetic-internal' rule chooses first level when there is not any modifiers
set and the second level when Shift is active. If Lock (without Shift) is set
it chooses the first level keysym but allow second step to make it uppercase
one (using internal table !).
But the case Lock+Shift is processed differently. 'Two level' rule chooses
the second level symbol but 'alphabetic-internal' rule still gets the first
level keysym but consume Lock modifiers and prevents the capitalization at
the secont step.
Thus you see that the 'alphabetic-internal' rule *never* chooses the second
level if Lock is set but only pass it to or hide it from the second step.
The rule 'alphabetic' in caps:shift mode differ from both mentioned rules.
It *always* consume Lock and leave the second step idle. On the other hand
it use Lock for choosing the second level and returns to the first level
when Shift is added to Lock.
> > > 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.
No, I said that CapsLock key doesn't control Shift modifier (saying 'modifiers'
I don't mean keys themselvs but bit flags that the keys set).
The CapsLock key always set Lock modifier. But in this mode Lock and Shift
modifiers (flags) cause the same action at a level choosing.
> > 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?
Not exactly, but it looks like that. :-)
As I tried to explain above, "if the second shift level is alphabetic" (and
uppercase) the 'alphabetic' rul
Re: CapsLock behaviour and Turkish keyboard
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 {[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]
pgp0.pgp
Description: PGP signature
Re: CapsLock behaviour and Turkish keyboard
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]
pgp0.pgp
Description: PGP signature
Re: CapsLock behaviour and Turkish keyboard
Hi,
> 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...)
Well, I can make an option (what about "caps:lockshift" name) that shifts
ALL keys but it can't be canceled with Shift key pressing.
> > Probably ConvertCase procedure doesn't know how to convert it to uppercase.
>
> Where is the list of internal case pairs ?
There is XConvertCase subroutine in xc/lib/X11/KeyBind.c but deals with keysym
ranges and you need to figure out falls a paticular keysym into some range
or not.
> > 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?
It's a very simple program (I attached it). It just prints all keysyms of the
current keyboard map. Therefore I ran it from a batch file like
setxkbmap al
maptest > al.map
setxkbmap be
maptest > be.map
...
and then compare files with 'diff'.
> 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 ] )
OK.
> Mmmh; I don't see any difference in behaviour at all between caps:shift
> and caps:internal !
Even for 'tr' and 'az' keyboard ?!
('az' uses the same idotles/I and i/Iabovedot pairs as 'tr')
Also I found a difference for [oe, OE] key in 'fr-latin9' map. But it rater
a bug in XConvertCase and I think it's already fixed in the current sources
(I tested it under 4.3.0).
> 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".
Hmm. Don't know. Can you tell about all conditions?
What caps mode you tested with? What keymap do you mean? There is not such
key in existent maps. Did you write it yourself? If so, don't you forget
to copy the file into both directories (xkb/symbols for old layouts and
xkb/symbols/pc for new ones)?
In my tests (a wrote such key description myself) it always is recognized
as 'two level' (it seems like a bug in xkbcomp; probaly it doesn't recognizes
Greek keysyms as letters at all) and always gives 'A'.
> (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")
BTW. Do you know that xkbcomp 'summarizes' new options with already set ones?
If you run it once as "setxkbmap -option caps:shift", to replace
the mode you have to run it second time as
setxkbmap -option "" -option caps:shift
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
#include
#include
XKeyEvent ev;
Display *dpy;
main(argc, argv)
int argc;
char **argv;
{
KeyCode keycode;
KeySym keysym;
int GroupMask, max, min;
dpy = XOpenDisplay(0);
if(!dpy) { printf("Can't open display\n"); exit(0);};
ev.type = KeyPress;
ev.display = dpy;
ev.state = 0;
ev.keycode = 0;
XDisplayKeycodes(dpy, &min, &max);
for(keycode = min; keycode < max; keycode++) {
ev.keycode = keycode;
printf ("%3d : ", keycode);
ev.state = 0;
XLookupString(&ev, NULL, 0, &keysym, NULL);
printf ("%s ", XKeysymToString(keysym));
ev.state = ShiftMask;
XLookupString(&ev, NULL, 0, &keysym, NULL);
printf ("%s ", XKeysymToString(keysym));
ev.state = LockMask;
XLookupString(&ev, NULL, 0, &keysym, NULL);
printf ("%s ", XKeysymToString(keysym));
ev.state = ShiftMask | LockMask;
XLookupString(&ev, NULL, 0, &keysym, NULL);
printf ("%s ", XKeysymToString(keysym));
/* New layouts */
GroupMask = Mod5Mask;
/* Old layouts*/
/* GroupMask = 1<<13; */
ev.state = GroupMask;
XLookupString(&ev, NULL, 0, &keysym, NULL);
printf ("%s ", XKeysymToString(keysym));
ev.state = GroupMask | ShiftMask;
XLookupString(&ev, NULL, 0, &keysym, NULL);
printf ("%s ", XKeysymToString(keysym));
ev.state = GroupMask | LockMask;
XLookupString(&ev, NULL, 0, &keysy
Re: CapsLock behaviour and Turkish keyboard
Pablo Saratxaga wrote:
> On Wed, Aug 06, 2003 at 01:31:45AM +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.
> 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 suggested to change Lock modifier behavior (XKB allows it) to make it
: > simply choose keysym from second column as Shift do.
:
: But that behaviour won't be welcome in all cases, for example on French and
: Balgian keyboards there is:
:
:key {[ccedilla, 9 ]
:
: CapsLock allows to type a Ccedilla; changing CapsLock behaviour will make
: it impossible.
( http://marc.theaimsgroup.com/?l=xfree-i18n&m=99365248027276&w=2 )
I realize that "make it default" and my suggestion "change the behavior
completely" are different things. But if we change the defaults now ...
1) most of user will not notice any differences but
2) French or Belgian keyboard users will be surprised unpleasantly.
> 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. 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.
In "caps:internal mode" (the default) Xlib gets a keysym from the first level
(or 'column' in core protocol terms) but then converts it to another keysym
using a builtin table.
> Note also that /usr/X11R6/lib/X11/xkb/README.enhancing is outdated, it
> doesn't talk about "caps:shift"
This README was not written as a reference book for all options.
Such description can be found in xkb/rules/xfree86.lst or xfree86.xml file.
And those files are mentioned in the README.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
Kaixo! On Tue, Aug 05, 2003 at 09:38:59AM -0400, Owen Taylor wrote: > On Tue, 2003-08-05 at 08:55, Ivan Pascal wrote: > > > Yes. There *was* such problem and it was discussed year ago. :-) > > (I don't remember but I was sure you took part in that discussion.) Yes. > > Now Turkish keyboard users just have to set XkbOption "caps:shift". but it is not very satisfactory. as Owen says: > I don't think that this is a particularly good way to handling things. > Using caps:shift produces all sorts of strange behavior - for example, > the number keys will give their shifted variants. > > The Turkish user might well wonder why everybody else gets a useful > caps lock key, while they have this monstrosity. We can also tell Turkish users not to use CapsLock; or live with a casing that doesn't corresponds to their locale... but those aren't real solutions, only workarounds. I thought it was too difficult to fix back then; but now I see that special behaviour for numeric pad is added; so why not a small handling for Turkish style casing ? > It should be possible in Xlib's code for handling > lock == Caps_Lock to simply special case this; if the lower case > key is 'i', then check to see whether the key in the second level > is 'I' or 'Idotabove', and act accordingly. Such one is a nice idea, it wouldn't even need the introduction of a special keyword. If someone knows where on Xlib code that casing is done, I may take a look at it. Thanks -- 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] pgp0.pgp Description: PGP signature
Re: CapsLock behaviour and Turkish keyboard
Kaixo! On Wed, Aug 06, 2003 at 01:31:45AM +0700, Ivan Pascal wrote: > > On Tue, 2003-08-05 at 08:55, Ivan Pascal wrote: > > > Now Turkish keyboard users just have to set XkbOption "caps:shift". > I risk to seem impolite but did you try this option before making such > assertion? If you tried you would notice that it is not true. Mmh, indeed it seems to work (I only tested a handful letters, but it seems ok). The name was misleading I thought it was the system where capslock is similar to shift lock (how is that mode named then?) And why isn't "caps:shift" made the default? It doesn't seem to change anything for other layouts (after some quick tests). > > The Turkish user might well wonder why everybody else gets a useful > > caps lock key, while they have this monstrosity. > > Do you have real complains from Turkish users? Well, I regularly do. Now that I know it, I would ensure that caps:shift is set for the keyboards needing it. > I want to assure you it works as expected. CapsLock affects alphabetic keys > only. XKB automaticaly recognizes what keys are 'letter' ones. Shift > key being pressed cancels CapsLock action. What is wrong? Why isn't that the default CapsLock behaviour? And what is exactly the difference between the caps:shift and the currently default behaviour? > Of course, you may add a 'specila case' kludge to Xlib. But the problem you > want to solve doesn't exist actually. Thanks. Note also that /usr/X11R6/lib/X11/xkb/README.enhancing is outdated, it doesn't talk about "caps:shift" > -- > Ivan U. Pascal | e-mail: [EMAIL PROTECTED] >Administrator of | Tomsk State University > University Network | Tomsk, Russia > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel -- 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] pgp0.pgp Description: PGP signature
Re: CapsLock behaviour and Turkish keyboard
On Tue, 2003-08-05 at 10:18, Pablo Saratxaga wrote: > > It should be possible in Xlib's code for handling > > lock == Caps_Lock to simply special case this; if the lower case > > key is 'i', then check to see whether the key in the second level > > is 'I' or 'Idotabove', and act accordingly. > > Such one is a nice idea, it wouldn't even need the introduction of a special > keyword. > > If someone knows where on Xlib code that casing is done, I may take a look > at it. It's easy enough to do for non-XKB (xc/lib/X11/KeyBind.c:_XTranslateKey) but trickier for XKB, which is what we care about. For XKB, the relevant code is in XKBBind.c:XkbTranslateKeySym(). One with the XKB code is that the people writing it knew just enough about internationalization to be dangerous; there is some structure in there for *character set* dependent conversion of keyboard symbols (which is never right, tr_TR.UTF-8 and en_US.UTF-8 have the same character set), but if you look deeper, it actually isn't used; it ends up as a hardcoded call to XConvertCase() currently. So, this structure can probably just be ignored. The other problem is that by the time we get to XkbTranslateKeySym, we've lost track of what what key was pressed, so you'd probably need to have an internal variant of XkbTranslateKeySym that takes keycode information as well, and call that from XLookupString(). Regards, Owen [ Don't try to test this stuff with GTK+; the Xlib code isn't involved for either non-XKB or XKB. ] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
On Tue, 2003-08-05 at 08:55, Ivan Pascal wrote: > Hi, > > > I see keyboard topics are being discussed right now... > > there is long standing problem with the CapsLock and turkish keyboard > > that would be nice to have fixed. > > Yes. There *was* such problem and it was discussed year ago. :-) > (I don't remember but I was sure you took part in that discussion.) > > Now Turkish keyboard users just have to set XkbOption "caps:shift". > With that option Xlib doesn't use 'internal capitalization' but CapsLock > key acts as 'locking Shift' (but can be canceled by Shift key). It solves > the problem. I don't think that this is a particularly good way to handling things. Using caps:shiftproduces all sorts of strange behavior - for example, the number keys will give their shifted variants. The Turkish user might well wonder why everybody else gets a useful caps lock key, while they have this monstrosity. It should be possible in Xlib's code for handling lock == Caps_Lock to simply special case this; if the lower case key is 'i', then check to see whether the key in the second level is 'I' or 'Idotabove', and act accordingly. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
Hi, > I see keyboard topics are being discussed right now... > there is long standing problem with the CapsLock and turkish keyboard > that would be nice to have fixed. Yes. There *was* such problem and it was discussed year ago. :-) (I don't remember but I was sure you took part in that discussion.) Now Turkish keyboard users just have to set XkbOption "caps:shift". With that option Xlib doesn't use 'internal capitalization' but CapsLock key acts as 'locking Shift' (but can be canceled by Shift key). It solves the problem. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
