Custom Query (308 matches)

aus linux/X/TODO

Den dead_stroke sollte man wieder einkommentieren, leider funktioniert das noch nicht auf älteren Systemen (z. B. Debian 3.x). Und außerdem bewirkt er leider sowieso noch gar nichts. Siehe eigene Ergänzungen zu X.org in „Compose“ und „Readme.Compose“.

aus linux/X/TODO

Compose und Caps gehen noch nicht richtig (Compose nur rechts, Caps nur links)

Behandelt in der Mail: Re: [neo] an die Linuxer: Treiber fertig machen für Xorg vom: 04.07.2008 22:37

Fehlerbeschreibung

Kurz

Wenn in der Xmodmap oder der Xkbmap unter Linux für eine Taste implies angegeben wird, sollte eigentlich laut /usr/include/X11/keysymdef.h das im Kommentar erwähnte Zeichen erscheinen:

⇒ (U+21D2 RIGHTWARDS DOUBLE ARROW)

Es erscheint jedoch das hier: ⊢ (U+22A2 RIGHT TACK)

Kommentare und Ergänzungen

Ist Euch übrigens schon aufgefallen, dass in den offiziellen Unicodetabellen beim Zeichen ⊢ als Kommentar steht:

Aliasnamen:

• turnstile
• proves, implies, yields x
• reducible

Also auch implies! Bei diesem Zeichen aber nicht „⇒“. Ha. Da hat sicher einer der Programmierer geschlampt.

Wo melden wir das? X-Bug, oder?

Hier die Zeile aus der /usr/include/X11/keysymdef.h:

#define XK_implies                       0x08ce  /* U+21D2 RIGHTWARDS DOUBLE ARROW */

Aber was bedeutet der Code 0x08ce? Ich kann den nirgends finden. Ganz oben in der Einführung der Datei /usr/include/X11/keysymdef.h wird ja noch die Datei xc/lib/X11/KeyBind.c erwähnt. Vielleicht ist da ersichtlich, dass es wirklich falsch ist.

So, ich teste das mal: export GTK_IM_MODULE=xim && gucharmap

Tatsächlich, wenn ich nun versuche den Pfeil ⇒ einzugeben, erscheint dieses komische andere Zeichen. Also ist es wirklich falsch in der /usr/include/X11/keysymdef.h (oder deren Abhängigkeiten) definiert. Da haben die Gnome das mal richtig gemacht, was die Xer falsch gemacht haben (denn unter Gnome erscheint normalerweise immer der richtige ⇒).

Bugreport? An wen? Wer schreibt den? Erst danach sollten wir dieses Ticket schließen.