neo/neo-layout
18
15
Fork 25
Code Issues 77 Pull Requests 3 Releases Wiki Activity

Bugs melden #46

New Issue
Closed
opened 2008-09-11 09:22:00 +02:00 by Sepp · 15 comments
Sepp commented 2008-09-11 09:22:00 +02:00
Copy Link

Es sind an mehrere Projekte Bugs zu melden:

X.org (1)

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

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 ⇒).

X.org (2)

in der Datei /usr/include/X11/keysymdef.h sind uptack und downtack vertauscht!

X.org (3)

Abkürzungen (Greek_SIGMA usw.) für griechische Großbuchstaben funktionieren nicht in xmodmap und xkbmap

Siehe Mail: Re: [neo_layout] an Pascal: Zeichenkürzel ←→ Unicodeabkürzungen vom: 02.04.2008 12:42

und Mail: Re: [neo] an die Linuxer: Treiber fertig machen für Xorg vom: 01.07.2008 16:39

Fehlerbeschreibung

Geht nicht wenn

Griechischen Großbuchstaben erscheinen bei der Eingabe nicht, wenn man sie in der Xmodmap bzw. Xkbmap als Abkürzungen (Greek_SIGMA usw.) angibt, wie sie in der Datei /usr/include/X11/keysymdef.h stehen. Und zwar weder unter KDE noch unter Gnome.

Geht schon wenn

Nur wenn man die Unicodezeichen als UTF16-Kürzel angibt (z.B. U03A3 für Greek_SIGMA), erscheinen sie bei der Eingabe auch.

Hinweise

Der Fehler tritt auf, seitdem die 6. Ebene per Mod3+Mod4 erreicht wird. Vorher, mit Umschalt+Mod4, funktionierte es ohne Probleme.

Vorläufige Lösung

UTF16-Kürzel verwenden und als Kommentar das Zeichen angeben, für welches das UTF16-Kürzel steht.

Nachteil

Fehleranfällig, weil zwei voneinander unabhängige Angaben.

X.org (4)

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

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

xmodmap

  1. Man muss vor xmodmap neo_de.xmodmap immer setxkbmap ie ausfühern, sonst geht folgendes nicht:

  2. die 4 auf der 4. Ebene

  3. bei der alten xmodmap (ohne KP-Hack)

  4. W, Ä und » gehen nicht unter xterm und Konsorten (stattdessen Einfg usw.)

  5. fast kein Buchstabe der linken Tastaturhälfte funktioniert unter xedit, xfig und ähnlichen Programmen

  6. bei der neuen xmodmap (mit KP-Hack)

  7. gehen die Bewegungstasten auf der 4. Ebene nicht mehr (in keinem Programm), wenn Numlock aktiviert ist (betrifft nur Thinkpads (oder?))

  8. nicht alle Probleme können durch den KP-Hack gelöst werden:

  9. bei xpdf: ö geht nicht (stattdessen Tab), Ö macht rücktab

  10. bei xedit: v geht nicht (stattdessen Backspace), ebenso V

X.org (5)

Wenn man den PC mit anderen Teil, die QWERTZ tippen, ist ein Umschalten mittels Umschalt+Umschalt (Shift+Shift) recht praktisch. Jedoch:

xkbmap

  1. Wenn man es so lädt
        Option      "XkbLayout" "de,de"
        Option      "XkbVariant" "basic,neo"
        Option      "XkbOptions" "grp:shifts_toggle,grp_led:scroll" # ctrls_toggle und alts_toggle ist in Xorg kaputt, siehe Bug 4927

dann gehen nur die ersten 4 Ebenen in Neo (nachdem man mit Strg+Strg von QWERTZ zu Neo gewechselt hat).
Wenn man es jedoch umgekehrt einträgt "XkbVariant" "neo,basic" dann geht alles.

  1. Mit setxkbmap de neo funktioniert immer alles. Man kann danach aber nicht mehr mit Strg+Strg zurückschalten. Murks.

Gnome/GTK (1)

Im gnome-terminal kann man normalerweise mit Strg++ und Strg+- (also Strg und + bzw. - gleichzeitig gedrückt) das Fenster vergrößern und verkleinern. Funktioniert aber mit Neo 2 (12. Okt. 2008, xkbmap) nicht!

In Firefox (auch GTK-Programm, oder?) geht es.

Siehe außerdem Fehler in gedit (wahrscheinlich gleiches Problem), siehe Ticket #89.

Swing (Java)

Siehe Ticket #129 und #104.

Es sind an mehrere Projekte Bugs zu melden: # X.org (1) **Behandelt in der Mail:** Re: [neo] an die Linuxer: Treiber fertig machen für Xorg **vom:** 04.07.2008 22:37 ## 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 ⇒). # X.org (2) in der Datei /usr/include/X11/keysymdef.h sind uptack und downtack vertauscht! # X.org (3) Abkürzungen (Greek_SIGMA usw.) für griechische Großbuchstaben funktionieren nicht in xmodmap und xkbmap Siehe **Mail:** Re: [neo_layout] an Pascal: Zeichenkürzel ←→ Unicodeabkürzungen **vom:** 02.04.2008 12:42 und **Mail:** Re: [neo] an die Linuxer: Treiber fertig machen für Xorg **vom:** 01.07.2008 16:39 ## Fehlerbeschreibung ### Geht nicht wenn Griechischen Großbuchstaben erscheinen bei der Eingabe nicht, wenn man sie in der Xmodmap bzw. Xkbmap als Abkürzungen (*Greek_SIGMA* usw.) angibt, wie sie in der Datei */usr/include/X11/keysymdef.h* stehen. Und zwar weder unter KDE noch unter Gnome. ### Geht schon wenn Nur wenn man die Unicodezeichen als UTF16-Kürzel angibt (z.B. *U03A3* für *Greek_SIGMA*), erscheinen sie bei der Eingabe auch. ### Hinweise Der Fehler tritt auf, seitdem die *6. Ebene* per *Mod3+Mod4* erreicht wird. Vorher, mit *Umschalt+Mod4*, funktionierte es ohne Probleme. ## Vorläufige Lösung UTF16-Kürzel verwenden und als Kommentar das Zeichen angeben, für welches das UTF16-Kürzel steht. ### Nachteil Fehleranfällig, weil zwei voneinander unabhängige Angaben. # X.org (4) Manche Buchstaben gehen nicht in den Anwendungen *xterm, xfig, xpdf, xedit* usw. 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 ### 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 2. bei der alten xmodmap (ohne KP-Hack) 1. W, Ä und » gehen nicht unter xterm und Konsorten (stattdessen Einfg usw.) 1. fast kein Buchstabe der linken Tastaturhälfte funktioniert unter xedit, xfig und ähnlichen Programmen 3. 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?)) 4. nicht alle Probleme können durch den KP-Hack gelöst werden: 1. bei xpdf: ö geht nicht (stattdessen Tab), Ö macht rücktab 1. bei xedit: v geht nicht (stattdessen Backspace), ebenso V # X.org (5) Wenn man den PC mit anderen Teil, die QWERTZ tippen, ist ein Umschalten mittels Umschalt+Umschalt (Shift+Shift) recht praktisch. Jedoch: ### xkbmap 1. Wenn man es so lädt ``` Option "XkbLayout" "de,de" Option "XkbVariant" "basic,neo" Option "XkbOptions" "grp:shifts_toggle,grp_led:scroll" # ctrls_toggle und alts_toggle ist in Xorg kaputt, siehe Bug 4927 ``` dann gehen nur die ersten 4 Ebenen in Neo (nachdem man mit Strg+Strg von QWERTZ zu Neo gewechselt hat). Wenn man es jedoch umgekehrt einträgt *"XkbVariant" "neo,basic"* dann geht alles. 2. Mit *setxkbmap de neo* funktioniert immer alles. Man kann danach aber nicht mehr mit Strg+Strg zurückschalten. Murks. # Gnome/GTK (1) Im *gnome-terminal* kann man normalerweise mit Strg++ und Strg+- (also Strg und + bzw. - gleichzeitig gedrückt) das Fenster vergrößern und verkleinern. Funktioniert aber mit Neo 2 (12. Okt. 2008, xkbmap) **nicht**! In Firefox (auch GTK-Programm, oder?) geht es. Siehe außerdem Fehler in gedit (wahrscheinlich gleiches Problem), siehe Ticket #89. # Swing (Java) Siehe Ticket #129 und #104.
erik commented 2008-10-12 23:44:12 +02:00
Member
Copy Link

Zur Ernüchterung: Diese Präsentation, in der erklärt wird, dass der xkeyboard-config-Code totaler Murks ist, und eigentlich keiner durchblickt. Vielleicht können manche Fehler trotzdem behoben werden.

Wichtige Adressen für die Behebung der Fehler

Zur Ernüchterung: [Diese Präsentation](http://people.freedesktop.org/~daniels/talks/fosdem-xkb.pdf), in der erklärt wird, dass der xkeyboard-config-Code totaler Murks ist, und eigentlich **keiner** durchblickt. Vielleicht können manche Fehler trotzdem behoben werden. ## Wichtige Adressen für die Behebung der Fehler * Hier wird xkeyboard-config entwickelt: http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Development * Hier kann man alles Fragen, und Profis geben die Antworten: http://community.livejournal.com/xkbconfig/ * [Hier](http://wiki.freedesktop.org/wiki/KeyboardInputDiscussion) wird ganz unten in den Kommentaren erklärt, dass xkb von xmodmap abhängt, dass xmodmap ein Bestandteil von X.org ist und xkb nur eine Erweiterung!! Das wird Pascal freuen – irgendwie. ;-) * Das [GIT-Repo](http://cgit.freedesktop.org/xkeyboard-config/) * Wenn wir Neo 2 in X.org aufnehmen lassen wollen, müssen wir [diese Regeln](http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Rules) erfüllen (klappt noch nicht ganz, siehe Abschnitt *Layouts, Variants* Punkt 1 und Punkt 6* ⇒ oh nein!). * An die [Mailingliste von xkb](http://listserv.bat.ru/xkb/List.html?Language=) kann man hier schreiben: [mailto:xkb@listserv.bat.ru] * An diesen Daniel (der Typ hat auch obige Präsentation erstellt) könnte man auch die GTK/Gnome-Fehler melden: [Megalange URL](https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=xorg&component=Input%2FXKB&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=)
erik commented 2008-10-14 07:59:40 +02:00
Member
Copy Link

Fehler an X.org kann man hier melden: https://bugs.freedesktop.org/enter_bug.cgi?product=xkeyboard-config

Fehler an X.org kann man hier melden: https://bugs.freedesktop.org/enter_bug.cgi?product=xkeyboard-config
erik commented 2008-10-14 12:20:20 +02:00
Member
Copy Link

Für die Fehler X.org (1) und X.org (2) gibt es hier die aktuelle keysymdef.h.

Für die Fehler X.org (1) und X.org (2) gibt es [hier](http://cgit.freedesktop.org/xorg/proto/xproto/tree/) die aktuelle [keysymdef.h](http://cgit.freedesktop.org/xorg/proto/xproto/tree/keysymdef.h).
erik self-assigned this 2008-10-14 13:17:32 +02:00
erik commented 2008-10-14 13:17:32 +02:00
Member
Copy Link

X.org (2) wurde gemeldet und behoben. Siehe http://cgit.freedesktop.org/xorg/proto/xproto/log/ am 14. Oktober 2008.

X.org (2) wurde gemeldet und behoben. Siehe http://cgit.freedesktop.org/xorg/proto/xproto/log/ am 14. Oktober 2008.
pascal commented 2008-10-14 23:25:47 +02:00
Copy Link

X.org (3) wurde gelöst.
Die Zeichen werden immer in Gruppen zu zwei angeordnet. Ist eine Gruppe nur halb definiert (also ein statt zwei Einträgen), wird der entsprechende Kleinbuchstabe genommen.

Beispiel: keycode 24 = A
Diese Zeile erzeugt ein kleines(!) a und mit Shift ein großes, obwohl es so gar nicht definiert ist.
Aber: keycode 24 = A x
Mit dieser voll definierten Gruppe werden die Zeichen genauso erzeugt wie sie definiert sind.

Unser Problem:
Die vierte Gruppe war halb definiert und hat darum einen Kleinbuchstaben erzeugt. Es muss also irgend etwas (nicht NoSymbol!) dort stehen, um die Gruppe zu füllen. Dann funktioniert alles.

X.org (3) wurde gelöst. Die Zeichen werden immer in Gruppen zu zwei angeordnet. Ist eine Gruppe nur halb definiert (also ein statt zwei Einträgen), wird der entsprechende Kleinbuchstabe genommen. Beispiel: keycode 24 = A Diese Zeile erzeugt ein kleines(!) a und mit Shift ein großes, obwohl es so gar nicht definiert ist. Aber: keycode 24 = A x Mit dieser voll definierten Gruppe werden die Zeichen genauso erzeugt wie sie definiert sind. Unser Problem: Die vierte Gruppe war halb definiert und hat darum einen Kleinbuchstaben erzeugt. Es muss also irgend etwas (nicht NoSymbol!) dort stehen, um die Gruppe zu füllen. Dann funktioniert alles.
erik commented 2008-10-15 14:28:19 +02:00
Member
Copy Link

Replying to Sepp nix@da:

X.org (1)

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)

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.

Habe die Datei gefunden, wo die Keysyms in Unicode-Zeichen gewandelt werden (als Konstanten definiert). Und zwar in der Datei src/xlibi18n/imKStoUCS.c. In Zeile 123 steht tatsächlich das falsche Zeichen für 0x08ce (vorletztes in der Zeile), nämlich 0x22a2 statt 0x21d2.

Testen kann ich es allerdings nicht, weil ich nicht geübt im Kompilieren von X.org bin.

Replying to [Sepp <nix@da>](./issues/46): > # X.org (1) > ## 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*) > > 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. Habe die Datei gefunden, wo die Keysyms in Unicode-Zeichen gewandelt werden (als Konstanten definiert). Und zwar in der Datei [src/xlibi18n/imKStoUCS.c](http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/xlibi18n/imKStoUCS.c). In Zeile 123 steht tatsächlich das falsche Zeichen für 0x08ce (vorletztes in der Zeile), nämlich 0x22a2 statt 0x21d2. Testen kann ich es allerdings nicht, weil ich nicht geübt im Kompilieren von X.org bin.
erik commented 2008-10-15 15:27:12 +02:00
Member
Copy Link

X.org (3) wurde gelöst.
Die Zeichen werden immer in Gruppen zu zwei angeordnet. Ist eine Gruppe nur halb definiert (also ein statt zwei Einträgen), wird der entsprechende Kleinbuchstabe genommen.

Ich habe die Datei gefunden, in der Definiert wird, bei welchen Zeichen genau das passiert. Es ist die Datei KeyBind.c ab Zeile 306 bis Zeile 644.

Ich schätze, das sind auch die Zeichen, die mit Capslock verändert werden. Gut zu wissen, wie ich finde.

> X.org (3) wurde gelöst. > Die Zeichen werden immer in Gruppen zu zwei angeordnet. Ist eine Gruppe nur halb definiert (also ein statt zwei Einträgen), wird der entsprechende Kleinbuchstabe genommen. Ich habe die Datei gefunden, in der Definiert wird, bei welchen Zeichen genau das passiert. Es ist die Datei [KeyBind.c](http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/KeyBind.c) ab Zeile 306 bis Zeile 644. Ich schätze, das sind auch die Zeichen, die mit Capslock verändert werden. Gut zu wissen, wie ich finde.
erik commented 2008-10-25 00:26:30 +02:00
Member
Copy Link

Replying to Sepp nix@da:

X.org (1)

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)

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.

Habe die Datei gefunden, wo die Keysyms in Unicode-Zeichen gewandelt werden (als Konstanten definiert). Und zwar in der Datei src/xlibi18n/imKStoUCS.c. In Zeile 123 steht tatsächlich das falsche Zeichen für 0x08ce (vorletztes in der Zeile), nämlich 0x22a2 statt 0x21d2.

Testen kann ich es allerdings nicht, weil ich nicht geübt im Kompilieren von X.org bin.

Bernd Steinhauser hat es getestet. Es funktioniert! Habe es gestern an Peter Hutterer von Red Hat gemeldet. Hoffentlich lädt er den Patch bald hoch (dann wäre X.org 7.5 befreit von dem Fehler).

> Replying to [Sepp <nix@da>](./issues/46): > > # X.org (1) > > ## 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*) > > > > 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. > > Habe die Datei gefunden, wo die Keysyms in Unicode-Zeichen gewandelt werden (als Konstanten definiert). Und zwar in der Datei [src/xlibi18n/imKStoUCS.c](http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/xlibi18n/imKStoUCS.c). In Zeile 123 steht tatsächlich das falsche Zeichen für 0x08ce (vorletztes in der Zeile), nämlich 0x22a2 statt 0x21d2. > > Testen kann ich es allerdings nicht, weil ich nicht geübt im Kompilieren von X.org bin. Bernd Steinhauser hat es getestet. Es funktioniert! Habe es gestern an Peter Hutterer von Red Hat gemeldet. Hoffentlich lädt er den Patch bald hoch (dann wäre X.org 7.5 befreit von dem Fehler).
erik commented 2008-10-25 00:32:31 +02:00
Member
Copy Link

Fehler in Xorg verhindert weitere Verwendung von alts_toggle und ctrls_toggle (Fehler gefunden, aber erfordert ein Neuschreiben von xkbcomp → keiner hat Bock drauf (seit 2005!)

Siehe Bugreport: http://bugs.freedesktop.org/show_bug.cgi?id=4927
und kleine Beschreibung des Fehlers: http://bbs.archlinux.org/viewtopic.php?id=50353

Novells/Suses Lösung: Ignorienen und einfach nicht mehr anbieten! Naja… https://bugzilla.novell.com/show_bug.cgi?id=373197

Daher diese Änderung in der Beschreibung.

Fehler in Xorg verhindert weitere Verwendung von alts_toggle und ctrls_toggle (Fehler gefunden, aber erfordert ein Neuschreiben von xkbcomp → keiner hat Bock drauf (seit 2005!) Siehe Bugreport: http://bugs.freedesktop.org/show_bug.cgi?id=4927 und kleine Beschreibung des Fehlers: http://bbs.archlinux.org/viewtopic.php?id=50353 Novells/Suses Lösung: Ignorienen und einfach nicht mehr anbieten! Naja… https://bugzilla.novell.com/show_bug.cgi?id=373197 Daher diese Änderung in der Beschreibung.
erik commented 2009-01-14 22:13:28 +01:00
Member
Copy Link

Replying to Sepp nix@da:

X.org (1)

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)

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.

Habe die Datei gefunden, wo die Keysyms in Unicode-Zeichen gewandelt werden (als Konstanten definiert). Und zwar in der Datei src/xlibi18n/imKStoUCS.c. In Zeile 123 steht tatsächlich das falsche Zeichen für 0x08ce (vorletztes in der Zeile), nämlich 0x22a2 statt 0x21d2.

Testen kann ich es allerdings nicht, weil ich nicht geübt im Kompilieren von X.org bin.

Bernd Steinhauser hat es getestet. Es funktioniert! Habe es gestern an Peter Hutterer von Red Hat gemeldet. Hoffentlich lädt er den Patch bald hoch (dann wäre X.org 7.5 befreit von dem Fehler).

¡Endlich Fehler Xorg(1) behoben!

Hier: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=091c1624fd2f9d933329d6152e4ecd865aa7903a

> > > Replying to [Sepp <nix@da>](./issues/46): > > > # X.org (1) > > > ## 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*) > > > > > > 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. > > > > Habe die Datei gefunden, wo die Keysyms in Unicode-Zeichen gewandelt werden (als Konstanten definiert). Und zwar in der Datei [src/xlibi18n/imKStoUCS.c](http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/xlibi18n/imKStoUCS.c). In Zeile 123 steht tatsächlich das falsche Zeichen für 0x08ce (vorletztes in der Zeile), nämlich 0x22a2 statt 0x21d2. > > > > Testen kann ich es allerdings nicht, weil ich nicht geübt im Kompilieren von X.org bin. > > Bernd Steinhauser hat es getestet. Es funktioniert! Habe es gestern an Peter Hutterer von Red Hat gemeldet. Hoffentlich lädt er den Patch bald hoch (dann wäre X.org 7.5 befreit von dem Fehler). ### ¡Endlich Fehler Xorg(1) behoben! Hier: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=091c1624fd2f9d933329d6152e4ecd865aa7903a
pascal commented 2009-01-15 08:34:55 +01:00
Copy Link

Den Fehler „X.org (3)“ habe ich vor über 3 Monaten behoben. Vorschlag: Ticket (vielleicht auch in Teilen) wieder neu anlegen.

Den Fehler „X.org (3)“ habe ich vor über 3 Monaten behoben. Vorschlag: Ticket (vielleicht auch in Teilen) wieder neu anlegen.
erik commented 2009-04-22 03:13:41 +02:00
Member
Copy Link

Auch der Fehler, der oben als X.org (5) bezeichnet wird ist mit r1803 endlich behoben. Als Nicht-Allein-Nutzer meines PC-Systems hat das den Vorteil, dass ich weder auf Ebene 4 verzichten muss, noch die anderen Nutzer mit Neo plagen muss (weil das Wechseln ja mit Umschalt+Umschalt (hier in der Fehlerbeschreibung und bei mir zu Hause) oder Scroll-Lock (siehe offizielle Anleitung) ganz einfach ist).

Somit bleiben noch ungelöst:

  • X.org (4) und
  • Gnome/GTK (1),
    welche vielleicht tatsächlich in eigene Tickets verschoben werden sollten, sofern sie nicht noch ganz schnell und einfach gelöst werden können, um dieses Ticket hier endlich schließen zu können.
Auch der Fehler, der oben als [X.org (5)](http://wiki.neo-layout.org/ticket/46#X.org5) bezeichnet wird ist mit r1803 **endlich** behoben. Als Nicht-Allein-Nutzer meines PC-Systems hat das den Vorteil, dass ich weder auf Ebene 4 verzichten muss, noch die anderen Nutzer mit Neo plagen muss (weil das Wechseln ja mit Umschalt+Umschalt (hier in der Fehlerbeschreibung und bei mir zu Hause) oder Scroll-Lock (siehe [offizielle Anleitung](wiki/Neo-unter-Linux-einrichten%2Fxkbmap#AktivierenundDeaktivierensch%C3%B6nundeinfach)) ganz einfach ist). Somit bleiben noch ungelöst: * [X.org (4)](http://wiki.neo-layout.org/ticket/46#X.org4) und * [Gnome/GTK (1)](http://wiki.neo-layout.org/ticket/46#GnomeGTK1), welche vielleicht tatsächlich in eigene Tickets verschoben werden sollten, sofern sie nicht noch ganz schnell und einfach gelöst werden können, um dieses Ticket hier endlich schließen zu können.
anonymous commented 2009-05-12 15:15:47 +02:00
Copy Link

Somit bleiben noch ungelöst:

  • [ticket:46#X.org4 X.org (4)] und
  • [ticket:46#GnomeGTK1 Gnome/GTK (1)],
    welche vielleicht tatsächlich in eigene Tickets verschoben werden sollten, sofern sie nicht noch ganz schnell und einfach gelöst werden können, um dieses Ticket hier endlich schließen zu können.

So, der Fehler „[ticket:46#X.org4 X.org (4)]“ ist auch zufriedenstellend gelöst. Mit einem FAQ-Eintrag, der auf Andreas’ ausführliche Anleitung verweist.

Wer löst das [ticket:46#GnomeGTK1 Gnome/GTK (1)]-Problem?

> Somit bleiben noch ungelöst: > * [ticket:46#X.org4 X.org (4)] und > * [ticket:46#GnomeGTK1 Gnome/GTK (1)], > welche vielleicht tatsächlich in eigene Tickets verschoben werden sollten, sofern sie nicht noch ganz schnell und einfach gelöst werden können, um dieses Ticket hier endlich schließen zu können. So, der Fehler „[ticket:46#X.org4 X.org (4)]“ ist auch zufriedenstellend gelöst. Mit einem [FAQ-Eintrag](wiki/FAQ#IchkannunterxtermundxeditkeinVWoder%C3%84schreiben.Waskannichdagegentun), der auf Andreas’ ausführliche Anleitung verweist. Wer löst das [ticket:46#GnomeGTK1 Gnome/GTK (1)]-Problem?
Stephan commented 2009-06-15 14:31:43 +02:00
Copy Link

Könnte hier jemand das Java-Swing-Problem, wie es in #129 und #104 beschrieben wird, hinzufügen?

Könnte hier jemand das Java-Swing-Problem, wie es in #129 und #104 beschrieben wird, hinzufügen?
hrnz commented 2020-10-26 16:05:30 +01:00
Owner
Copy Link

Somit bleiben noch ungelöst:

  • [ticket:46#X.org4 X.org (4)] und
  • [ticket:46#GnomeGTK1 Gnome/GTK (1)],
    welche vielleicht tatsächlich in eigene Tickets verschoben werden sollten, sofern sie nicht noch ganz schnell und einfach gelöst werden können, um dieses Ticket hier endlich schließen zu können.

So, der Fehler „[ticket:46#X.org4 X.org (4)]“ ist auch zufriedenstellend gelöst. Mit einem FAQ-Eintrag, der auf Andreas’ ausführliche Anleitung verweist.

Wer löst das [ticket:46#GnomeGTK1 Gnome/GTK (1)]-Problem?

in gnome-terminal funktioniert mittlerweile das Ändern der Schriftgröße mit Ctrl-+ und Ctrl--. Gedit hat die Funktion nicht mehr.

> > > Somit bleiben noch ungelöst: > > * [ticket:46#X.org4 X.org (4)] und > > * [ticket:46#GnomeGTK1 Gnome/GTK (1)], > > welche vielleicht tatsächlich in eigene Tickets verschoben werden sollten, sofern sie nicht noch ganz schnell und einfach gelöst werden können, um dieses Ticket hier endlich schließen zu können. > > So, der Fehler „[ticket:46#X.org4 X.org (4)]“ ist auch zufriedenstellend gelöst. Mit einem [FAQ-Eintrag](wiki/FAQ#IchkannunterxtermundxeditkeinVWoder%C3%84schreiben.Waskannichdagegentun), der auf Andreas’ ausführliche Anleitung verweist. > > Wer löst das [ticket:46#GnomeGTK1 Gnome/GTK (1)]-Problem? in gnome-terminal funktioniert mittlerweile das Ändern der Schriftgröße mit Ctrl-+ und Ctrl--. Gedit hat die Funktion nicht mehr.
hrnz closed this issue 2020-10-26 16:05:30 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
(╯°□°）╯︵ ┻━┻

   
Bug

   
Diskussion

Besprechungen zu einem Thema mit offenem Ausgang

  
Dokumentation

   
Duplikat

Ähnliche Issues vorhanden

  
Gitea

   
Hardware

   
Hilfe

Unterstützung gesucht

  
Invalid

   
Java

   
Lernen

Tipptrainer und andere Hilfsmittel

  
Qt

   
Remote

VM, Remote Desktop usw.

  
Subversion

   
Tablet

   
Tastaturbelegung

   
Test

   
Treiber/Android

   
Treiber/iOS

   
Treiber/Linux/Konsole

   
Treiber/Linux/xkb

   
Treiber/Linux/xmodmap

   
Treiber/MacOS

   
Treiber/Windows/AHK

   
Treiber/Windows/kbdneo

   
Treiber/Windows/ReNeo

   
Verbesserung

   
Website

   
Windows 11

   
Wontfix

Wird nicht behoben

  
Worksforme
No Label
(╯°□°）╯︵ ┻━┻
Bug
Diskussion
Dokumentation
Duplikat
Gitea
Hardware
Hilfe
Invalid
Java
Lernen
Qt
Remote
Subversion
Tablet
Tastaturbelegung
Test
Treiber/Android
Treiber/iOS
Treiber/Linux/Konsole
Treiber/Linux/xkb
Treiber/Linux/xmodmap
Treiber/MacOS
Treiber/Windows/AHK
Treiber/Windows/kbdneo
Treiber/Windows/ReNeo
Verbesserung
Website
Windows 11
Wontfix
Worksforme
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
erik
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: neo/neo-layout#46
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?