Re: Georgian XKB symbol map
Kaixo! On Wed, Jan 15, 2003 at 03:01:02PM +0400, Nugzar Nebieridze wrote: > Hello. > > I am a new user to this list, and unfortunately I do not know XKB very > well, but for the current moment, I have written KA-symbol map for > XFree86 4.1 (Debian Woody). So, I can type Georgian Unicode characters > in X server now. XFree86 includes I think Georgian keymaps, look at /usr/X11R6/lib/X11/xkb/symbols/ for ge_la and ge_ru > I would like to controbute this file to XFree if it is possible, and I > would like to know whether I did everything correctly. Whom should > I contact? First check the above keymaps, and if yours is only a variant of one of them you should add a variant inside of the file instead of making a different file. PS: it's possible that those files were added in 4.2 only, I don't remember when I sent them; -- 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] msg00143/pgp0.pgp Description: PGP signature
Re: xkb bug in XFree 4.2.99.3
Kaixo!
On Thu, Jan 23, 2003 at 07:48:30AM -0500, Marc Deslauriers wrote:
> I am trying RedHat's latest beta which includes XFree 4.2.99.3 and there
> is a bug in the xkb code. I cannot configure a proper French Canadian
> keyboard. When specifying "ca_enhanced" in the XF86Config file, some
> keys on the keyboard are not mapped properly.
>
> For instance, the right alt meta key does not work.
> I cannot type a c-cedilla "ç" using the keyboard either.
Apparently 4.2.99.5 works better for that.
However, chars typed with AltGr have still problems for use in compose
sequences, eg if I have to type AltGr-2 to have
I can't type an n-tilde with , ,
the sequence is defined hoiwever, and if I put the asciitilde keysym
somewhere else, accessible directyl without AltGr, then it works.
I'm also unable to make the key work as a compose key;
I put
= { [ Multi_key ] };
and "xev" tells me that a "Multi_key" keysym is sent; but it has no
effect at all on composing sequences...
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]
msg00221/pgp0.pgp
Description: PGP signature
Re: xkb bug
Kaixo!
I have more info. using 4.2.99.5.
> However, chars typed with AltGr have still problems for use in compose
> sequences, eg if I have to type AltGr-2 to have
> I can't type an n-tilde with , ,
> the sequence is defined hoiwever, and if I put the asciitilde keysym
> somewhere else, accessible directyl without AltGr, then it works.
I confirm this problem.
> I'm also unable to make the key work as a compose key;
> I put
>
>= { [ Multi_key ] };
>
> and "xev" tells me that a "Multi_key" keysym is sent; but it has no
> effect at all on composing sequences...
This one however, only happens with programs compiled with a previous
version of xfree, with newly compiled programs it works.
There are other problems:
* the "< >" key is not defined by default (I'll probably add it
to the latin file, unless there is some real reason why it has been
left out ?)
* in Emacs, when you type a char accessible trough AltGr, you like of
"lose the focus".
For example to search for "@" you type, Ctrl-S (that puts you in
the "command" buffer at the bottom of the window, where you can
then type the string to search) then '@'.
on a French keyboard '@' is in AltGr-0; however, as soon as the
AltGr key is pressed the "focus" goes to the main edit buffer,
thus it the '@' char will be typed in the text being edited and
not in the command buffer, that means it is impossible to search
a string with a char that must be typed with AltGr key.
This is with GNU Emacs 21.2.93.1 compiled with the 4.2.99.5 xfree libs
(with a version compiled with 4.2 libs previous to the 4.2.99 ones
that problem didn't showed up, even when using emacs on a system
with 4.2.99.5)
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]
msg00225/pgp0.pgp
Description: PGP signature
CapsLock behaviour and Turkish keyboard
Kaixo!
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.
The problem is that when CapsLock is set, XFree86 does an uppercasing
of the letters, so typing 'a' with CapsLock set gives 'A' etc.
*BUT* in Turkish (and Azeri too), the 'I' is not the uppercase of the 'i'.
In fact in Turkish there are two kind of "i", one with dot (with a *dotted*
uppercase letter) and one without dot (with 'I' as uppercase, and a dotless
lowercase one).
The turkish keyboard has:
key { [ idotless,I ] };
key { [ i,Iabovedot ] };
it works well, except for the CapsLock mode.
In previous versions of XFree86, it was somewhat bypassed by redfining
CapsLock to some group switching function and tweaking the groups, eg:
key { [ ISO_Next_Group, ISO_Next_Group], [ ISO_Prev_Group, ISO_Prev_Group ] };
...
key { [ q, Q ], [ Q, q ] };
...
key { [ idotless, I ], [ I, idotless ] };
key { [ i, Iabovedot ], [ Iabovedot, i ] };
...
key { [ period, colon ], [ period, colon ] };
you get the idea.
But of course it was an ugly hack, and it doesn't work anymore with the
new version of XFree86...
Imho it should be fixed at the right place: where XFree86 does ther current
uppercasing.
With a new keyboard to tell that a given keyboard layout wants to use the
Turkish uppercasing scheme (there are three layouts that would use
it; "tr Q" (modern turkish), "tr F" (traditional turkish) and "az" (Azeri))
so the layout remains simple:
key { [ idotless,I ] };
key { [ i,Iabovedot ] };
without tricks; and in config file, some special option tells
that the turkish casing scheme iswanted; eg: "case:turkish" or something
like that.
Or maybe (better imho) defining that in the layout file itself;
something like:
key { [ q, Q ] };
...
key { type[group1] = "TURKISH", [ idotless, I ] };
key { type[group1] = "TURKISH", [ i,Iabovedot ] };
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
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 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
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
