Custom Query (308 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1 - 3 of 308)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#1 fixed Linux: implies, Implikationspfeil: falsches Zeichen wird ausgegeben Erik Streb del Toro
Description

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.

#2 fixed Linux: xterm, xfig, xpdf, xedit und ähnliche machen Probleme (Fehler!) Erik Streb del Toro
Description

Diskutiert wurde dies schon in diversen Mails. Zum Beispiel in der

Mail: Re: [neo] KP_Workaround ist ungeschickt vom: 28.06.2008 16:05

und in der

Mail: Re: [neo] Steuerung von Programmen mit der NEO (Beispiel: mplayer) vom: 04.07.2008 23:32.

Fehlerbeschreibung

Kurz

Manche Buchstaben gehen nicht in den Anwendungen xterm, xfig, xpdf, xedit usw.

Ausführliche Berichte (weitere in den Mails)

xkbmap

  1. Wenn man es so lädt
            Option      "XkbLayout" "de,de"
            Option      "XkbVariant" "basic,neo"
            Option      "XkbOptions" "grp:ctrls_toggle"
    
    

dann gehen nur die ersten 4 Ebenen (nach Strg+Strg). Wenn man es jedoch umgekehrt einträgt "XkbVariant" "neo,basic" dann geht es.

  1. Mit setxkbmap de neo dann geht immer alles

xmodmap

  1. Man muss vor xmodmap neo_de.xmodmap immer setxkbmap ie ausfühern, sonst geht folgendes nicht:
    1. die 4 auf der 4. Ebene
  1. bei der alten xmodmap (ohne KP-Hack)
    1. W, Ä und » gehen nicht unter xterm und Konsorten (stattdessen Einfg usw.)
    2. fast kein Buchstabe der linken Tastaturhälfte funktioniert unter xedit, xfig und ähnlichen Programmen
  1. bei der neuen xmodmap (mit KP-Hack)
    1. gehen die Bewegungstasten auf der 4. Ebene nicht mehr (in keinem Programm), wenn Numlock aktiviert ist (betrifft nur Thinkpads (oder?))
  1. nicht alle Probleme können durch den KP-Hack gelöst werden:
    1. bei xpdf: ö geht nicht (stattdessen Tab), Ö macht rücktab
    2. bei xedit: v geht nicht (stattdessen Backspace), ebenso V
#3 fixed [ahk] In GTK-Anwendungen lassen sich keine Unicodezeichen eintippen tim@…
Description

In GTK-Anwendungen funktionieren bestimmte Tastenkürzel nicht. Wenn ich ALT+% zum Beispiel in Emacs drücke kommt ein % und es wird nicht der Befehl zum Ersetzen von Text ausgeführt.

Ich benutze AHK Variante von NEO 2.0 aus dem SVN.

1 2 3 4 5 6 7 8 9 10 11
Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.