Bug 75079
Summary: | canadian french keyboard layout only works fully with some apps | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Gray Kimbrough <jgk3> |
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | otaylor |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-11-26 00:59:18 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Gray Kimbrough
2002-10-04 05:44:38 UTC
Please report bugs like this directly to the upstream maintainer of the package. Closing WONTFIX Actually, note: gaim/xchat/Mozilla => GTK+-1.2 apps => Use Xlib input handling gedit/gnome-terminal => GTK+-2.0 apps => Use builtin input handling So this is apparently a Xlib problem ... more particularly, a problem with the compose sequences for your locale in /usr/lib/X11/locale/ What locale are you running in - that is, what does 'echo $LANG' give from a terminal? [jgk3@tertiary jgk3]$ echo $LANG en_US.UTF-8 Wow, that's a pretty insane keyboard layout ;-) The 'i' key seems to be completely unmodified from the standard en layout though, as opposed to many other keys. It looks to me that it doesn't give anything with the 3rd-level-shift. I'm not sure what you mean by 'apostrophe' here; there are various acute like things you could be trying to get: a single vertical quotation mark (what would be used for an apostrophe in ASCII text) a right single quotation mark (what would normally be used for an apostrophe in printing) a standalone acute accent (a line angled to the right) Can you specify exactly what keys you want to press (identify them by where they are in respect to the alphabetic keys on the keyboard "the key to the left of the l" with what modifiers (AltGR and 3 level shift, if you understand what keys those are, otherwise where tehy are on the keyboard) and what output you want to get on the screen. Thanks. I agree that it's rather insane, but quite nice to be able to type two languages, and a wealth of symbols, as well... Typing any non-standard characters seems to be a problem in xchat, where, e.g. i--found to the left of the right shift key--outputs as two characters. The standalone accent acute mark, which would normally be a left quotation mark, I believe, is generally produced by altGr-i, twice. Doing this in mozilla or xchat has no effect now, i.e. nothing is produced. The standalone grave accent works, produced by twice hitting the key which is two keys to the right of L. On the plus side, I figured out how to make an apostrophe--that is, a vertical quotation mark--which on this keyboard amounts to shift-comma. So, the main problem is dealing with nonstandard characters like i and 5, and the acute accent. For those following along at home: The character to the left of right-shift is eacute unshifted AltGr + that key gives dead_acute. (Basically, don't try to enter i18n characters into bugzilla, it will just mangle them; I've never seen any luck in this area :-) There is indeed a difference bewteen dead_acute + dead_acute in the iso-8859-1 and en_US.UTF-8 compose sequences... in the iso-8859-1 sequences, dead_acute + dead_acute gave acute (pretty useless really) while for the en_US.UTF-8 compose sequences it acts as a "dead doubleacute" (pretty useless unless you need to type in some Hungarian.) In neither case did it give a single vertical quotation mark. (') Shift-comma is most likely the simplest way of getting '. Also you can get it as dead_acute + space. dead_grave + dead_grave is going to give you a standalone grave, which is useful if you are doing shell or Perl programming, but not otherwise. I don't think thjere is actually a bug here. (Well, there is a bug in that the GTK+ compose tables and the en_US.UTF_8 Xlib compose tables don't agree on the interpretation of dead_acute + dead_acute, but I'll save worrying about that until some Hungarian complains.) |