Re: [Neo] ADNW?
Bei AdNW machen mir alleine schon e und i auf Mittel- und Ringfinger große Bauchschmerzen. Das lädt Sehnenscheidenentzündung geradezu ein (schlimmer wäre nur kleiner Finger und Ringfinger). Wolf hat eine Zeitlang eine AdNW-artige Belegung benutzt, bei der e und i nicht nebeneinander liegen. Letztlich ist er wieder davon abgekommen, wegen Nachteilen bei anderen Bigrammen. Für meinen gemischten Korpus (deutsch-englisch 1:1) sind die Anzahl aller Bigramme, bei denen linker Mittel- und Ringfinger direkt nacheinander zum Einsatz kommen bei AdNW gerade mal 10% höher als bei cry. Im Vergleich zu AdNW spielt sich bei cry mehr davon abseits der Grundlinie ab, so dass man nicht sagen kann, ob die Belastung durch diese Bigramme bei AdNW überhaupt höher ist. Sobald man die beiden Bigramme nicht isoliert betrachtet ist es also nicht offensichtlich, warum «ei» und «ie» ein Problem für AdNW sein sollten. → „eh“ als sehr häufiges Bigramm geht vom Mittel- auf den Kleinen Finger und wird als gut bewertet, was völlig meiner Tipperfahrung widerspricht. (cry wurde übrigens für 30% englischen, 70% deutschen Korpus optimiert) «eh» liegt in der Rangfolge der Bigramme im gemischten Korpus auf Platz 168, im deutschen Korpus auf Platz 96. Für den gemischten Korpus ist es nur 10% häufiger als «sh», was bei cry diesselbe Bewegung auf der anderen Hand ist. Fazit wie oben. (die Grafiken finde ich übrigens sehr schön. Nur die darin gezeigten Ergebnisse zweifle ich an) Solange man den Farben keine Bedeutung zumisst geben die Grafiken lediglich den Inhalt der Häufigkeitstabellen wieder. Zusätzlich habe ich vor 2 Wochen gelernt, dass die Arbeitswissenschaftliche Fakultät des KIT (Uni Karlsruhe) ein Modell der Hand hat, mit dem Belastungsrechnungen durchgeführt werden können (ich habe zufällig einen der Wissenschaftlichen Mitarbeiter der Fakultät bei einer Weiterbildung getroffen). Hast du dazu mehr Informationen (Links, Publikationen)? Andreas
Re: [Neo] ADNW?
dazu möchte ich anmerken, dass mich sehr stört, dass D und T nebeneinander liegen. Ich schreibe nicht wirklich blind und nicht richtig 10-Finger, sondern igendwas dazwischen mit eher 8 Fingern. Langer Rede kurzer Sinn, ich verwechsle gerne mal nebeneinanderliegende Tasten und bei DT ist das besonders blöd, weil es nicht wie ein Tippfehler, sondern wie ein Rechtschreibfehler aussieht. Bei ADNW liegen D und T auch nebeneinander. Bei anderen Buchstaben ist mir das noch nicht aufgefallen. Wie Klaus schon angetönt hat, kann der Optimierer verhindern, dass «ähnliche» Buchstaben auf «verwechselbare» Tasten kommen. Vor zwei Jahren gab es auf AdNW-Liste (damals noch NordTast-Liste) eine Diskussion zu dem Thema. Aus der Diskussion entstand die Belegung «DIEgO». Ein paar Leute haben damit eine Weile getippt, sind nach anfänglicher Begeisterung aber zu ihren vorherigen Belegungen zurück. Nach dieser Erfahrung vermuten wir, dass eine Belegung besser zu lernen ist, wenn ähnliche Buchstaben so liegen, dass man ihre Tasten nicht leicht verwechselt. Aber die dadurch erzwungenen Beschränkungen bringen Nachteile an anderer Stelle. Zumindest für DIEgO haben letztere überwogen. Für DIEgO wurden recht viele Buchstabenpaare als ähnlich betrachtet. Es ist denkbar, dass man sich auf weniger Paare beschränken und so eine Belegung finden kann, bei der die Nachteile der Ähnlichkeitsbehandlung durch die Vorteile aufgewogen werden. Leider ist Ähnlichkeit nicht für jeden dasselbe, und daher ist es nicht klar, ob man mit wenigen (sagen wir, zwei) Paaren auskommt und doch den meisten Anwendern damit weiterhilft. Andreas
Re: [Neo] Erfahrungsbericht aus dem IRC
http://synergy-foss.org/spit/issues/details/3329/ Falls die Analyse von Mathias Baumann stimmt und der Client durch das Neo-Mod4 verwirrt wird könnte man den hier beschriebenen Workaround ausprobieren: http://wiki.neo-layout.org/ticket/129#comment:44 und ihn gegenfalls auf Ebene 3 ausweiten (das ksh-Skript auf der adnw.de-Downloadseite hat das schon eingebaut, aber halt nur für AdNW. Für Neo habe ich lokal noch eine alte Skriptversion). Andreas
Re: [Neo] Meta (Alt) und Super (Win) vertauschen
Woran kann das liegen? Irgendwelche Erfahrungswerte? Keine Ahnung. Hast du mal probiert, die Vertauschung so zu machen wie die manpage von xmodmap es für das Vertauschen von Control und Caps Lock vorführt, also mit 'remove' statt mit 'clear'? Andreas
Re: [Neo] Awesome WM
1. Im awful.prompt funktionieren die höheren Ebenen 2 nicht. Awesome ist (oder war bis vor kurzem) nicht XKB-tauglich. Die Beschränkung ist von ursprünglich von xcb geerbt. Darüber hinaus scheint awesome auch nicht voll core-protocol-tauglich zu sein, was auf Deutsch heisst, die xmodmap wird vermutlich auch nicht gehen. Für XKB gibt die Möglichkeit, die höheren Ebenen auf Ebene 1 und 2 anderer Tasten abzubilden. Für die wichtigen ASCII-Zeichen auf Ebene 3 gibt es für «Aus der Neo-Welt» eine fertige Lösung, siehe Option '-szd' für das Skript auf https://sites.google.com/site/ausderneowelt/. Ich habe auch noch eine ältere Skript-Variante mit Neo- und NordTast-Unterstützung die ich dir bei Interesse schicken kann, die ich aber nicht mehr unterstütze. Andreas
Re: [Neo] Awesome WM
Awesome ist (oder war bis vor kurzem) nicht XKB-tauglich. Die Beschränkung ist von ursprünglich von xcb geerbt. Heißt das, Awesome wird in der nächsten Version XKB-tauglich sein? Nein, das heisst nur, dass ich awesome nicht verfolge und daher nicht weiss, ob sich letzthin etwas geändert hat. Immerhin, wie es aussieht, wird zumindest bei XCB an Untestützung für XKB gearbeitet. Andreas
Re: [Neo] vim und cscope-Erweiterung: Tastatürkürzel Strg + \ funktioniert nicht
Verrückt: Das Strg + Mod 3-Problem habe ich nun nicht mehr unter Vim. Ich habe selbst mal mit AdNW/CH und AdNW/DE-Doppelbelegungen probiert und dabei auf die Redirect-Tricks meines Treibers verzichtet und noch ein paar kleine andere Änderungen gemacht, so dass mein Layout technisch etwa dem Neo von xkeyboard-config entspricht. Und dann kann ich das Problem reproduzieren… Wie gesagt: Bei mir spielte es keine Rolle, in welcher Reihenfolge ich Strg und Mod3 gedrückt habe. …aber nur, wenn ich erst Ctrl, dann Mod3 rechts drücke. Merkwürdig. Ich sehe das Problem sowohl mit DE- als auch mit CH-Zweitlayout; im letzteren Fall wird bei Ctrl+Mod3r ans Zeilenende gesprungen, denn auf hiesigen Tastaturen liegt auf Mod3r normalerweise $. Ausserdem tritt das Problem nicht nur mit vim, sondern auch mit nvi auf, und nicht nur, wenn der Editor in urxvt läuft, sondern auch in xterm. Es ist also nicht klar, in welchem Programm der Fehler steckt. Andreas
Re: [Neo] Eigenbau-Tastaturen
Die Frage die sich mir stellt ist eher, wie die Umsetzung der Diakritika-Taste erfolgen soll, ich bin keine Programmierer und ich könnte jetzt auch nicht so ohne weiteres den von mir benutzten Neo-Vars unter Windows entsprechend umgestalten. Das ist noch ein großes Fragezeichen für mich. Wenn du bereit wärst, die Diakritika-Taste vor dem Basiszeichen zu tippen (also q als ⸮k), dann kann man das unter X einfach mit Compose machen. Ich habe etwas ähnliches, die «Tote-q-Tastatur», eine Weile benutzt: https://lists.neo-layout.org/pipermail/diskussion/2010-February/015959.html Andreas
Re: [Neo] neo und stumpwm
hatte ja gehofft, jemand hätte schon mal eine Lösung gefunden... Ich hab's grad mal ausprobiert: Zumindest mit der Option -szd erzeugt das aktuelle AdNW.sh (von https://sites.google.com/site/ausderneowelt/) eine Belegung, mit der man in StumpWM die ASCII-Zeichen (auch auf Ebene 3) und Umlaute eingeben kann. Die Ebene 4-Navigation funktioniert auch, soweit ich feststellen kann. Als Lisp habe ich SBCL und für CLX die portable Version (http://gitorious.org/clx) genommen. Andreas
Re: [Neo] Potenziell bessere Methode der Layout-Optimierung
Die bisherigen Optimierer von Arne und Andreas berechnen beide eine Kostenfunktion für jedes generierte Layout. Diese Kostenfunktion ist frei von irgendwelchen Vorgaben. Bei dem neuen Ansatz müsste man sich der Form des QAPs unterwerfen. Mein Optimierer verwendet eine (leicht erweiterte) QAP Formulierung, und ich vermute, bei Arne ist es nicht viel anders. Das aufstellen der Matrizen A und B ist von der eigentlichen Optimierung getrennt. Die leicht Erweiterung in meinem Fall ist ein Term für gleichmässige Fingerbelastung (nichtlinear in den Buchstabenhäufigkeiten). Ausserdem gibt es auf Wunsch noch Trigramme, mit einem Summationsindex mehr. Bei Arne sieht es ähnlich aus, soweit ich weiss. • mittels Matrix C: Häufige Buchstaben auf guten Plätzen Nur dann, wenn man in C Häufigkeiten und Aufwände verwurstelt. Ich mache das nicht explizit, sondern habe Terme analog zu A*B, nur dass dort nur ein Summationsindex auftritt. So wie im Artikel formuliert würde C zum Beispiel erlauben auszudrücken, dass Belegungen, die eine Referenz-Belegung ähnlich sind besser sind als solche, die das nicht sind (Stichwort: Ctrl-XCV). Ich glaube Arne hat sowas, ich nicht. • Shiftkollisionen oder allgemeiner: Modifierkollisionen Allgemein über Optimierung auf mehreren Ebenen (mit Modifiern) habe ich mir noch keine näheren Gedanken gemacht. Prinzipiell lassen sich Shiftkollisionen durchaus berücksichtigen, allerdings bräuchten wir keine nxn-Matrix, sondern eine 2nx2n, was das QAP um einiges erschweren würde (unnötigerweise aus meiner Sicht). So schlimm ist es nicht. Der Aufwand vervierfacht sich nur (in einer naiven Implementierung), man hat ja nach wie vor nur n Tasten. • Es lassen sich durch (meta-)heuristische Methoden sehr schnell hinreichend gute Lösungen erzielen. Es erleichtert das Arbeiten an den Optimierungsparametern ungemein, wenn man sie einstellen und nach einigen Sekunden ein Layout präsentiert bekommt, das dem Optimum sehr nahe kommt. Der Arbeitszyklus: Parameter einstellen Gute Lösung finden Testen/Beurteilen Parameter verändern würde kürzer werden. Stimmt, Tempo ist wichtig, und ich behaupte, dass mein Optimierer deinen einige Sekunden nahe kommt. Es folgt eine kleine Buchstaben-Legende für die Ausgabe des hasqap-optimierers³, gleich gefolgt von dem Optimierungsprozess, bei dem immer die aktuell beste Lösung in Form einer Permutation ausgegeben wird. Auf Deutsch komme ich auf folgende Auswertung: Stephan 271.330 Gesamtaufwand 190.231 Lageaufwandlinks rechts 1.390 Kollisionen 17.048 Shift-Kollisionen ob 7.9 8.6 äuopü ßflmvx71.165 Handwechsel 18.134 Shift-Handwechsel mi 36.5 30.2 aietc gsnrhk 1.563 Ein-/Auswärts --.--- IndirKollision un 6.1 10.7 .öy,q dwjzb 15.796 benachbart 21.592 Shift-benachbart sum 50.5 49.5 10.3 11.2 18.0 11.1 --.- --.- 16.1 13.2 10.5 9.7 Sh 3.7 1.7 Nicht schlecht, es wird auch kein Finger über Gebühr belastet. Zum Vergleich: Aus der Neo-Welt 244.135 Gesamtaufwand 189.847 Lageaufwandlinks rechts 1.054 Kollisionen 2.155 Shift-Kollisionen ob 6.8 11.6 kuü.ä vgcljf71.373 Handwechsel 25.977 Shift-Handwechsel mi 34.5 32.5 hieao dtrnsß 1.525 Ein-/Auswärts --.--- IndirKollision un 5.4 9.2 xyö,q bpwmz 10.353 benachbart 22.340 Shift-benachbart sum 46.7 53.3 9.2 11.1 16.2 10.2 --.- --.- 16.5 10.9 15.4 10.5 Sh 3.8 1.6 Mit Englisch sieht es nicht ganz so gut aus, aber immer noch ok. Andreas
Re: [Neo] Potenziell bessere Methode der Layout-Optimierung
Der klare Vorteil einer strikten QAP-Formulierung ist, dass z.B. die Kostendifferenz zweier Belegungen, die sich nur um eine Vertauschung unterscheiden mit Rechenaufwand O(n) berechnet werden können (der Aufwand für die Neuberechnung der Kosten beläuft sich auf O(n^3) für ein QAP). Genauer gesagt ist der Rechenaufwand für die Bigramme proportional zu n²-(n-2)² bei Berechnung von Differenzen und n² bei Neuberechnung. Man reduziert den Rechenaufwand also ungefähr um den Faktor n/4. Für die Einzeltastenaufwände reduziert man den Aufwand von n auf 2, für Trigramme von n³ auf n³-(n-2)³. Das benutze ich natürlich. Die Behandlung der Anschlagshäufigkeit pro Finger ist nur O(n), daher ist es verschmerzbar, dass sie nicht ins QAP-Schema passen. Zwar hat man nur n Tasten, aber die QAP Beschreibung erfordert doppelt so viele. Das klingt mir eher als eine Beschränkung von speziellen Umsetzungen als der allgemeinen Beschreibung. Den Optimierer selbst zu implementieren hat halt Vorzüge. Andreas
Re: [Neo] neo und stumpwm
Ich habe Schwierigkeiten mit Neo (Xmodmap auf Linux) und Stumpwm (tiling window manager für X) -- wie sie schon Mitte 2010 von Eric Wolf berichtet wurden. Schwierigkeiten ist für eine Problembeschreibung etwas vage... Leider kann ich kaum Lisp, aber diese Funktion in input.list scheint mir verdächtig: (defun keycode-character (code mods) (let ((idx (if (member :shift mods) 1 0))) (xlib:keysym-character *display* (xlib:keycode-keysym *display* code idx) 0))) Sieht so aus, als ob alle Modifier ausser Shift weggeworfen würden. Die Minimalvariante für xkbmap mit 3 Ebenen stelle ich mir so vor: (let ((idx (if (member :shift mods) 1 (if (member :mod5 mods) 2 0 Allgemeiner müsste man die Menge in mods in einen state überführen, mit dem xlib:keysym-character etwas anfangen kann. Die Funktion is-modifier ist schon vom Interface her fehlerhaft: Unter Xlib bestimmt die keysym, was ein Modifier ist und was nicht, hier wird aber mit dem keycode gearbeitet. Bei dem Zeugs, was sich mit Modifiern zu befassen scheint sehe ich nirgends etwas, was Gruppenumschaltung betrifft. Das wäre für xmodmap fatal, denn Ebene 3 ist mit Gruppenumschaltung gemacht (keysym Mode_switch). Aber um wirklich nachzuverfolgen, was hier als Modifier und als Konsequenz daraus wie behandelt wird sind meine Lisp-Kenntnisse zu schwach. Da du vermutlich Lisp besser verstehst als ich solltest du dir input.lisp genauer anschauen. Ich vermute hier starken Verbesserungsbedarf. keysyms.lisp sollte man auch mal wieder nachführen. Andreas
Re: [Neo] Status Hardware-Präferenz
Es ist sehr wahrscheinlich, dass, falls sich einmal eine gute Nachfolgebelegung für Neo herausstellt, es eine Variante speziell für diese Tastatur geben wird, die deren Besitzer austauschen werden. Wolf hat das Thema auf der Nordtast-Liste angeschnitten, und wir sind zu folgender Belegung gekommen: 202.656 Gesamtaufwand 162.058 Lageaufwandlinks rechts 1.002 Kollisionen 0.000 Shift-Kollisionen ob 11.3 6.6 xzlcgb ä,üufß69.783 Handwechsel 0.000 Shift-Handwechsel mi 32.0 36.4 snrtd oaeih 1.705 Ein-/Auswärts5.514 IndirKollision un 6.5 3.1 vmwpj q.öyk 9.669 benachbart 22.961 Shift-benachbart sum 51.1 48.9 Finger 7.8 14.3 10.8 16.8 | 13.7 14.0 11.2 7.3 Shft 1.4 2.7 Da das TECK symmetrisch ist, kann man die Belegung natürlich auch spiegeln und kommt dann auf eine, die «Aus den Neo-Welt» ähnlich sieht. Die Variante oben hat aber XCV auf der linken Hand, was manche Anwender schätzen. Andreas
Re: [Neo] XKB-Treiber: Taste gleichzeitig als normale Taste und Modifier nutzen
Für die Arbeit mit XRECORD habe ich im Netz aber leider kein gutes Beispiel finden können. Da würde ich gerne auf dein Angebot eines Beispiels zurück kommen ;) Du musst nach keyloggern suchen, dann findest du bestimmt was. Ich habe mein Beispiel angehängt. Es wurde auf NetBSD-current getestet. Du musst in Zeile 9 die keycodes anpassen. Für deine Zwecke ist SHIFT_R_KEYCODE der keycode der physischen Taste, die Shift und n sein soll und N_KEYCODE ein unbenutzter keycode. Der erste dieser keycodes wird dann mit Shift, der zweite mit n/N belegt. Leider hängt das Programm, sobald man eine Belegung (xmodmap oder xkbcomp) läd. Man kann es immerhin neu starten. Aber dran denken, in der Zwischenzeit kannst du kein n mehr tippen. Ich habe die Ursache des Hängers noch nicht herausgefunden. Wenn du dahinter kommst lass es mich bitte wissen. Andreas record_xtest.C Description: Binary data
Re: [Neo] N-grame für GB, US Englisch, Deutsch und andere Sprachen
Ganz wertlos sind die n-Gramme natürlich nicht - man kann ja auch aus Wörtern (und Worthäufigkeiten) Buchstaben-n-Gramme (mit entspr. Häufigkeiten) erstellen. Solange es nur um Buchstaben geht, sollte das auch nicht schwierig sein. Man will aber vielleicht auch Zeichen-n-Gramme mit Satzzeichen oder Leerzeichen haben. Immerhin sind Punkt und Komma mit jeweils gut 1% häufiger als so mancher Buchstabe. Leerzeichen muss man spätestens dann mitnehmen, wenn man Zeichentrigramme (oder höhere n-Gramme) in der Optimierung berücksichtigt. Nun ist aber ein Wort gefolgt von einem Satzzeichen gemäss Google schon ein Wort-Bigramm, und zwei von Leerzeichen getrennte Wörter sowieso. Wenn man die Häufigkeit eines Zeichen-Trigramms «Satzzeichen Leerzeichen Buchstabe» haben will, braucht man dementsprechend schon die Google-Trigramme. Von letzteren gibt es 200 Files pro Sprache, das erste davon für Deutsch ist 65 MB komprimiert und 500 MB unkomprimiert gross. Und es ja so, dass bei einer Wortfolge W1 W2 ... Wn die Wort-Trigramme Worte W1 und Wn einmal in den Wort-Trigrammen vorkommen, W2 und W(n-1) zweimal, und die anderen dreimal. Wenn n nicht sehr gross ist wird dadurch also die naive Zählung der Zeichen-n-Gramme verfälscht. Ich glaube, bei Google ist n die Anzahl der Wörter pro Druckseite, was nicht allzu viel wäre. Man kann die Inkonsistenzen sicher rausrechnen, wenn man die Wort-2- und -1-Gramme mit berücksichtigt. Ziemlich viel Mühe dafür, den statistischen Fehler der Belegungsbewertung sinnlos klein zu machen. Andreas
Re: [Neo] XKB-Treiber: Taste gleichzeitig als normale Taste und Modifier nutzen
ich würde gerne eine Buchstaben-Taste (z.B. n) als Shift-Modifier nutzen, wenn sie gedrückt gehalten wird. Wird keine andere Taste gedrückt, soll die Taste sich „normal” verhalten. (D.h. jeweils ein XEvent für das Drücken und Loslassen der Taste gesendet werden.) Leider sehe ich keine Möglichkeit, die Reaktion auf die Eingabe auf das Loslassen der Taste zu verschieben. Weiß jemand, ob dies mit XKB realisierbar ist? Mit XKB geht das nicht. Mit der nächsten Version von libX11 kann man sowas mit Compose machen: Shift_R : n Aber dort, wo Compose nicht aktiv ist, funktioniert das nicht. Du brauchst daher zumindest ein n für Notfälle, das in der normalen Tastaturbelegung enthalten ist. Die meines Wissens beste Möglichkeit erfordert ein wenig programmieren. Mit der XRECORD Extension kann man die Tastatureingabe belauschen und mit der XTest Extension Tastatureingaben simulieren. Damit lässt sich das Gewünschte relativ einfach (100 Zeilen) umsetzen. Bei Bedarf kann ich ein Beispiel posten, das etwas von der Idee her Ähnliches macht. Andreas
Re: [Neo] XCompose: ♫sum funktioniert nicht
Trotz `~/.xinputrc` geht es immer noch nicht damit. Der folgende Befehl bringt auch keine Besserung. $ export DISABLE_IMSETTINGS=yes; export GTK_IM_MODULE=xim; gnome-terminal Leider habe ich noch nie eine brauchbare Dokumentation für «input methods» gesehen. Also rumprobieren. Vielleicht zusätzlich noch: export XMODIFIERS=@im=local oder export XMODIFIERS=@im=none Und dann vielleicht noch export XIM_PROGRAM= Oder durchforste deine Systemeinstellungen (oder Spracheinstellungen) nach ibus und SCIM und stelle sie gegebenefalls ab. ℜ ist eines dieser Neo-Mätzchen, die GTK wahrscheinlich nicht hat. Gut. Einen Fehlerbericht dafür konnte ich nicht finden, sodass ich nachher einen schreiben werde. Es ist weder ein Fehler von Neo, eine Sequenz für ℜ zu definieren, noch einer von GTK, das nicht zu tun. Andreas
Re: [Neo] XCompose: ♫sum funktioniert nicht
Heißt das, GTK ignoriert `~/.XCompose` und das ist so gewollt? Ja. In der Voreinstellung (ohne GTK_IM_MODULE und was sonst noch zu setzen) benutzt GTK die fest in GTK eingebauten Compose-Sequenzen. Andreas
Re: [Neo] XCompose: ♫sum funktioniert nicht
Ich habe die Umgebungsvariablen so in `~/.xinputrc` gesetzt. Auf manchen Systemen ist das richtige File ~/.xinput.d/LOCALE (also zum Beispiel ~/.xinput.d/de_CH) oder ~/.xinput.d/all_ALL. Wenn du im-switch auf deinem System hast siehst du das mit 'im-switch -l'. $ export DISABLE_IMSETTINGS=yes; export GTK_IM_MODULE=xim; gnome-terminal Probiere das nochmal, und zwar von einem xterm aus, und nachdem du alle anderen gnome-terminal zuvor geschlossen hast. Offenbar gibt es immer nur einen gnome-terminal-Prozess, der dann ein weiteres Fenster aufmacht, wenn man noch einmal gnome-terminal startet. Die Umgebungsvariablen für das Terminal sind also die, die beim Starten des ersten Terminalfensters aktiv waren. Hingegen läuft die Shell im neuen Terminalfenster natürlich mit den aktuellen Umgebungsvariablen... Andreas
Re: [Neo] XCompose: ♫sum funktioniert nicht
XKeysymToKeycode returns keycode: 105 Das sollte eigentlich keine Rolle spielen. Ich vermute, Pascal hat seine rechte Control-Taste in eine zweite Compose-Taste umfunktioniert. Über die GNOME Tastatureinstellungen habe ich meine Optionen nun Aber GNOME (bzw. GTK) könnte eine Rolle spielen. Siehe die FAQ: http://wiki.neo-layout.org/wiki/FAQ#BeimirfunktionierenmancheKombinationenmitderKombo-Compose-TasteoderdentotenTastenT1T2T3unterGnomeundGTK-Programmennicht. Andreas
Re: [Neo] XCompose: ♫sum funktioniert nicht
Vielen Dank für den Hinweis. Die auf der Seite beschriebenen Probleme habe ich nicht. Ich konnte alle genannten Kombinationen ohne Probleme unter GNOME erstellen. Vermutlich hat GTK die Composesequenzen in den Beispielen jetzt auch implementiert. Hast du die Umgebungsvariablen so gesetzt wie in der FAQ angegeben? Wenn nicht, tu es. Mein Problem ist übrigens auf einem anderen System mit Awesome als Fensterverwaltung auch vorhanden. Der Windowmanager ist egal. Du hast übrigens noch nicht geschrieben, welcher Anwendung du das ∑ zu entlocken versuchst, und das spielt eine Rolle. Bei ♫sum und ♫int wird in `xev` das Symbol angezeigt, aber im Fenster erscheint nur das letzte Zeichen (m oder t). xev ist halt kein GTK-Programm. Probiere mal ein xterm, da geht es bestimmt auch. Ich habe auch Kombinationen gefunden, die *nicht* funktionieren und die ein UTF-8 Zeichen erzeugen und aus zwei Buchstaben bestehen. Der Realteil ℜ erzeugt mit ♫re ist ein Beispiel dafür. ℜ ist eines dieser Neo-Mätzchen, die GTK wahrscheinlich nicht hat. Andreas
Re: [Neo] Howto: Write reversed Questionmark
Multi_key question question : ⸮ questionreversed # customized questionreversed ist keine Standard-keysym, daher solltest du sie hier weglassen, durch U2E2E ersetzen oder in deiner XKeysymDB definieren. Andreas
Re: [Neo] Grundlinie
Ein anderes Problem ist die Anpassung an eine spezifische Sprache. NEO ist speziell für die deutsche Sprache ausgerichtet. Allerdings schreibe ich auch viel in Englisch. Gibt es Layouts, die das berücksichtigen? «Aus den Neo-Welt» wurde mit gleichen Gewichten für Englisch und Deutsch optimiert. Andreas
Re: [Neo] terminal server client linux-windows
ich arbeite oft per tsc auf windowskisten und habe es bisher nicht geschafft eine zufriedenstellende lösung für neo gebastelt zu bekommen. hat es schonmal jemand geschafft oder könnt ihr mir tipps geben? Ich vermute, tsc beruht auf rdesktop, zumindest ist das für die Programme, auf die Google mich mit Terminal server client geführt hat der Fall. Du könntest rdesktop direkt verwenden, denn bei rdesktop kann man die Umsetzung der Tastendrücke mit eigenen Tabellen nach Wunsch steuern (Option -k): http://sf.own-it.nl/repositories/entry/otc/trunk/rdesktop-1.6.0/doc/keymapping.txt?rev=2 Einfach gesagt schaut rdesktop auf der Seite von X auf keysyms und setzt sie gemäss der Tabelle in Tastendrücke auf Windowsseite um. Daher muss die von rdesktop verwendete Tabelle zu der auf Windows-Seite eingestellten Belegung passen. 1. linux mit neo, windows mit de/us, keine angabe bei tsc ebene 4 pfeiltasten, return, del, backspace gehen, ebene 3 nicht nutzbar (total wirres mapping) Die Probleme mit Ebene 3 kommen vermutlich daher, dass Mod3 auf Windowsseite AltGr drückt, was nicht erwünscht ist, weil die meisten Zeichen von Ebene 3 in einer de-Belegung nicht auf der AltGr-Ebene liegen. Mit ISO_Level3_Shift 0x0 ignore Mode_switch 0x0 ignore (ersteres für xkbmap, letzteres für xmodmap) in deiner Tabelle kannst du das abstellen. Andreas
Re: [Neo] auch unter Ubuntu (Linux) Nordast als Umschalt + F12
Hallo Erik, Ich möchte gerne auch wie mit neo.exe unter Linux (bei mir Ubuntu) auf Nordtast wechseln können und zugleich die Neo Ebene 3 bis 6 behalten. Meine Neo-Umsetzung unterstützt auch NordTast. Umgeschaltet wird allerdings nicht mit F12, sondern mit ScrollLock. Siehe http://wettstae.home.solnet.ch/neo.sh.gz Warum geht das (noch) nicht? und wann wird es (vermutlich) gehen? Es besteht vermutlich zu wenig Bedarf. Andreas
Re: [Neo] Neo in Ubuntu 11.04
Mich wuerde eben nur interessieren, warum das Skript nicht automatisch startet, wenn ich mich einlogge. Bist du sicher, dass es nicht startet? ~/.profile wird von der Login-Shell ausgeführt, sollte daher von allen persönlichen Einstellungen als erstes dran kommen. Wenn die «Tastatur»-Einstellungen in den «Systemeinstellungen» später dran sind überschreiben sie die Einstellungen von ~/.profile. Probiere mal, des Skript über «Startprogramme» in den «Systemeinstellungen» laufen zu lassen. Andreas
Re: [Neo] Modifierpositionen
Über diese Möglichkeit hatte ich heute auch kurz nachgedacht - Ich habe auch noch mal drüber nachgedacht. Ich habe wieder mal das eigentliche Problem übersehen: Wenn man flüssig tippt, kommt es oft vor, dass man eine Taste anschlägt bevor man die vorherige loslässt. Eine Leertaste mit Nebenberuf Shift würde viele ungewollte Grossbuchstaben erzeugen. Aus dem Grund bin ich auch weitgehend von meinem Vorschlag mit Modifikatoren als toten Tasten abgekommen (ein alter Vorschlag, https://lists.neo-layout.org/pipermail/diskussion/2010-February/015959.html), auch wenn ich ihn für einen ganz speziellen Zweck nutze. Man könnte vielleicht die Key-Down/Ups unverändert ans System weiterreichen und Character-Messages produzieren, die so bei einem klassischen Treiber nicht von den Tastendrücken stammen können (z.B. eben kein Leerzeichen produzieren obwohl es Key Down und Up für die Leertaste gegeben hat). Aber auch das bringt Probleme mit sich, da man die Shift Taste nicht einzeln drücken könnte. Kombinationen wie Shift+Space würden auch problematisch. Das klingt nach Eingabemethode. Unter X leiten Anwendungen Tastenevents an diese weiter, und die Eingabemethode kann die Tastenevents filtern (dann ignoriert die Anwendung sie) oder durchlassen, und ausserdem Strings mit erzeugten Zeichen an die Anwendung zurückliefern. Die Eingabemethode könnte also Space abfangen (und von den folgenden Eingaben abhängig machen, was für einen String die Anwendung sehen soll) und Shift-Space durchlassen. Andreas
Re: [Neo] Chording für entspannteres Tippen
²: http://www.emacswiki.org/emacs/ControlLock Ein Control-Lock lässt sich mit XKB leicht machen. Das funktioniert dann für alle Programme, nicht nur für Emacs. ³: http://www.emacswiki.org/emacs/KeyChord Danke für den Link. Chording ist eine interessante Sache. Wichtig dabei ist, dass die Tasten nict (oft) in normalen Texten hintereinander vorkommen, damit die chords nicht ausversehen getriggert werden. Ausser der Buchstabenhäufigkeit könnte man auch die Lage der Tasten heranziehen. Insbesondere wird man kaum versehentlich Tasten gleichzeitig drücken, die eigentlich von selben Finger angeschlagen werden. Auf der linken Hand gibt es ein paar solche Kombinationen, die man auf gewöhnlichen Tastaturen mit versetzten Zeilen bequem mit zwei Fingern eingeben kann, zum Beispiel QWERTZ-ed. Leider ist es mit X nicht leicht, chording in allen Programmen zum Funktionieren zu bringen. Hat jemand Erfahrungen mit autokey? http://code.google.com/p/autokey/ bf, bh, bp, cd, cf, cg, cp, cq, cv, cw, cy, dc, dm, fm, fy, fz, gm, gy, hy, hz, iq, mv, mw, nx, pz, qr, qt, sx, sz, uu, uv, vy, ww, wy, yy uu als chord zu tippen dürfte auch mit cry schwierig sein… Andreas
Re: [Neo] Shortcut-Ebene
* technische Machbarkeit? Unter X geht es; mein «Aus den Neo-Welt»-Skript (http://wettstae.home.solnet.ch/AdNW.sh.gz) bietet das als Option an. Andreas
Re: [Neo] Zeitleiste von Neo
Auf Anregung von Arno hin habe ich mal einen ersten Entwurf einer Zeitleiste von Neo gemacht (Siehe Anhang). Anregungen sind natürlich sehr willkommen. Ich habe Einwände. Die harten Fakten: - «Aus der Neo-Welt» stammt nicht von Ende 2010, sondern von Mai 2010. Und die abweichende Meinung: - NordTast, «Aus der Neo-Welt» und HAEIK sollten nicht mit direkten Pfeilen verbunden werden. Sie wurden mit verschiedener Software (im Falle von NordTast teilweise manuell), verschiedenen Korpora («Aus der Neo-Welt» ist für Deutsch und Englisch optimiert, NordTast und HAEIK für Deutsch) und verschiedenen Kriterien erstellt. Bei den Kriterien kann man nicht mal behaupten, dass die einen Kriterien Weiterentwicklungen der anderen wären. - «Aus der Neo-Welt» hat eine Verbindung zu Neo (dem Projekt) insofern, als es aufgrund von Diskussionen auf der Neo-Mailingliste entstanden ist. Für NordTast kann man das nur bedingt behaupten. - Zu Neo 2.0 (dem Layout) besteht weder für NordTast noch «Aus der Neo-Welt» eine Verbindung. Beide legen lediglich die Position von 31 bzw. 32 Zeichen fest und weichen darin von Neo 2.0 stark ab. Die Entwurfskriterien für die Neo-Buchstabenpositionen haben keine Rolle gespielt. Alles, was sonst Neo 2.0 noch ausmacht, kann man mit NordTast und «Aus der Neo-Welt» kombinieren, braucht es aber nicht. - Vorgänger von NordTast und «Aus der Neo-Welt» sind eher die Klauslers, denn wir haben Klauslers Bewertungsschema von der Struktur her übernommen. Für «Aus den Neo-Welt» soll man auch Dvorak als Vorgänger ansehen; ich habe mich an seinen qualitativen Kriterien orientiert, auch denen, bei denen man ernsthaft bezweifeln kann, dass sie für Computertastaturen eine Rolle spielen. Aus meinen Sicht gibt es einen Entwicklungsstrang, der von Neo 1.0 nach Neo 2.0 geht. Auf diesem Strang ist dazugekommen, was Neo einzigartig macht: Die Ebene mit den ASCII-Sonderzeichen, die Ebene mit den Navigationstasten, die typographischen Kinkerlitzchen, die mathematischen Sonderzeichen und (in der Grafik nicht erwähnt) die Unterstützung von Sprachen durch neue tote Tasten und Composesequenzen. Neben diesem Strang liegen die neuen Layouts, die eher mit Dvorak als mit Neo zu tun haben, und eher einen Fächer als einen Strang bilden. Ob und und wie dieser Fächer und der Neo-Strang dann mit einem «Neo 3.0» zusammenhängen, das hängt von denen ab, die diese Verbindung herstellen wollen. Andreas
Re: [Neo] Control-X/C/V mit alternativen Belegungen
Hm drei Tasten zusammen sind ich für so eine häufige Tastenkombination vielleicht etwas umständlich. Rein prinzipiell könnte ich mir das aber auch noch ganz gut vorstellen (auch wenn ich M3+Alt auf der linken Seite vorziehen würde). Gegen einen drei-Tasten-Griff spricht neben der Bequemlichkeit auch, dass die meisten Tastaturen nicht alle Kombinationen von mehr als zwei gleichzeitig gedrückten Tasten richtig erkennen können. Bei einem Einhänder hat man auch nicht die Möglichkeit, allfälligen Problemen aus dem Weg zu gehen, indem man einen Modifier von der anderen Seite nimmt. Daniels Vorschlag hat den grossen Vorzug, dass er zu zwei Dritteln schon umgesetzt ist. Auf der Pseudo-Ebene (Ebene 7) gibt es nämlich Shift+Delete (Cut) und Shift+Insert (Paste). Dank Ebene 4 ist auch Control+Insert (Copy) mit der linken Hand zu greifen. Laut http://en.wikipedia.org/wiki/Cut,_copy,_and_paste sollten die Kombinationen mit Insert und Delete für Cut/Copy/Paste unter X mindestens so gängig sein wie Control+X/C/V. Ausserdem sind sie Emacs-kompatibel. Unter X wäre es demgemäss günstiger, einen Vorschlag wie zum Beispiel den von Robby sinngemäss über Insert und Delete statt dem Wortlaut nach über Control+X/C/V zu implementieren. Das ist erstmal Theorie. Es würde mich interessieren, ob jemand Anwendungen kennt, die unter X laufen, die Control+X/C/V für Cut/Copy/Paste unterstützen, aber Shift+Delete, Control+Insert und Shift+Insert nicht. Andreas
Re: [Neo] Windowstasten per Xmodmap zu AltGr (Mod4) machen?
X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 118 (X_SetModifierMapping) Value in failed request: 0x17 Serial number of failed request: 14 Current serial number in output stream: 14 Siehe http://wiki.neo-layout.org/ticket/189, insbesondere die Erklärung von Peter im sechsten Kommentar. Was bei xkbmap schief geht ist mir daraus aber nicht klar. Andreas
Re: [Neo] Neo-Dokumentation und weiteres
2) Desweiteren würde ich gerne die Webseite und Teile unseres Wikis übersetzen. Wie einfach/schwierig gestaltet sich so eine Multisprachenversion der Webseite? Wer würde dabei mithelfen? Je mehr Informationen insbesondere auch in Englisch verfügbar sind, desto besser. Vor ein paar Tagen hat Martin Engel eine Nachricht zu dem Thema geschickt. Zumindest bist du mit deinem Anliegen nicht ganz allein. 3) Mir ist vor kurzem ein Französisches Projekt über den Weg gelaufen: http://bepo.fr/wiki/Accueil Leider verstehe ich nicht so viel Französisch, aber die bemühen sich auch um i) eine Optimierung der Tastenposition nach ihrer Sprache und ii) die Eingabemöglichkeit vieler Zeichen (insbesondere Griechisch, etc.). Die könnten sich sehr für unser Ebenendesign interessieren, denn die haben anscheinend ein paar Sachen bzgl. ii) umständlicher gelöst. Ganz auf den Kopf gefallen sind die auch nicht. Sie haben offenbar schon mit zusätzlichen Ebenen experimentiert. Siehe: https://bugs.freedesktop.org//show_bug.cgi?id=21475 (das interessiert dich vielleicht auch so, es geht eigentlich um tote Tasten und um Griechisch). 4) Es ist irgendwie untergegangen: Wir hatten mal einen inoffiziellen Kyrillisch- und Griechisch-Modus gebastelt, die beide praktisch schon fertig waren. Ich hatte mir damals gewünscht, dass es einen einfachen Mechanismus gibt, um diese umzuschalten (Mod3-F1/2/3 oder so), habe aber nicht genug technische Expertise, um soetwas selbst umzusetzen. Ich habe inzwischen meinen monolithischen Treiber etwas umgeschrieben und dabei einen X-Modifier eingespart. Den könnte man für zusätzliche Ebenen benutzen. Und das wäre mehr als eine technische Fingerübung, denn die naive Methode mit Layoutumschaltung hat (unter X) einen Haken: Wenn man die lateinischen Buchstaben durch griechische oder kyrillische ersetzt, kann man keine Ctrl- und Alt/Meta-Codes der lateinischen Buchstaben eingeben. So eine Belegung ist nur bedingt brauchbar. Mit einem Layout mit vielen Ebenen kann man das korrigieren, mit mehreren simplen Layouts (groups in XKB) nicht. Allerdings ist die Methode mit den vielen Ebenen unhandlich. Da wäre es doch besser… 5) Da ich mich gerade für ein Auslandsstudium in Japan befinde, bin ich stark auf eine Eingabemethode wie ibus (ähnlich zu scim) in praktisch allen Programmen angewiesen. Diese ist jedoch inkompatibel zu allen möglichen Cokos und toten Tasten, die dadurch nicht mehr funktionieren. Im Wiki gibt es eine Anleitung, die sich aber darauf beschränkt, scim für Teile zu deaktivieren, was hier aber keine Lösung ist. Das ist eine relativ unbefriedigende Situation für mich, da ich seit einigen Monaten eben viele der Neo-Funktionen nicht nutzen kann. Hat jemand Lösungsvorschläge oder Ideen dazu? Man könnte im Prinzip für ibus eine verbesserte Compose-engine entwickeln und damit hübsche Sachen machen, zum Beispiel Tasten dynamisch töten und wiederauferstehen lassen. Das wäre ideal, um einen Griechisch- und Kyrillischmodus mit Compose (temporär totes a gibt α und so weiter) zu realisieren. Ctrl- und Alt/Meta-Sequenzen würde man immer am Leben lassen und hätte dieses Problem damit elegant gelöst. Dir würde auch geholfen sein, denn in ibus kann man zwischen verschiedenen engines umschalten. Ich habe vor ungefähr einem Jahr auf dieser Liste eine primitive ibus-engine vorgestellt, in der Hauptsache, um Modifikatortasten besser auszunützen, die aber als Zückerchen auch erlaubt, Unicodezeichen als vierstellige Hexzahl einzutippen. Siehe http://lists.neo-layout.org/pipermail/diskussion/2010-February/015959.html Das hat mir erstmal gereicht, weil es in Python war und ich Python eigentlich garnicht kann, und interessiert hat es sowieso niemanden. Völlig abwegig ist zumindest nicht, eine spezielle Neo-Compose-engine zu machen. Leider habe ich den Eindruck, dass Eingabemethoden, am liebsten garnicht oder zur Not wenigstens unverständlich dokumentiert sind. Das macht die Sache nicht einfacher. Vielleicht solltes du erst einmal herausfinden, ob ibus oder scim nicht doch eine Compose-engine mitbringen, und wenn ja, ob und wie man damit eigene Compose-Sequenzen definieren kann. Das würde zur Besitzstandswahrung schon reichen. Andreas
Re: [Neo] Windowstasten per Xmodmap zu AltGr (Mod4) machen?
Je nach Ausgangsbelegung kannst du etwas in der Art benutzen: keysym Super_L = ISO_Level5_Shift keysym Super_R = ISO_Level5_Shift clear mod4 Übrigens kann gerne AltGr mod4 sein und die Windowstaste daneben auch. Also kann ich wohl das clear weglassen. Oder verstehe ich das falsch? Naja, probieren geht über studieren. ;-) Das mod4 oben ist das X-Mod4, nicht das Neo-Mod4. Wenn du das X-Mod4 nicht mit löschst werden deine neue Neo-Mod4-Tasten auch X-Mod4 setzen. Das ist vielleicht Ursache für die Probleme, die du in der zweiten Antwort beschreibst. Daneben hängt wie erwähnt die Änderung, die du machen musst, von der Ausgangsbelegung ab. Der Vorschlag oben sollte funktionieren, wenn du die Neo-xkbmap verwendest, und wenn die Windowstasten wie üblich Super-Tasten sind. Wenn du die Neo-xmodmap verwendest brauchst du statt ISO_Level5_Shift ISO_Level3_Shift, falls ich mich recht erinnere. Ich würde empfehlen, die geänderte Belegung mit xev zu testen. Dann sieht man zumindest, was los ist. Achso, statt einer Xmodmap, sollte ich’s lieber mit setxkbmap … versuchen? Wie würde das dann aussehen? Probier mal (nicht getestet, weil ich kein Neo mehr kann): setxkbmap de neo -option lv5:lwin_switch_lock,lv5:rwin_switch_lock Andreas
Re: [Neo] Control-X/C/V mit alternativen Belegungen
Wenn die Alternative XCV Belegung eine Neo Belegung stört wäre das echt schade. Man verliert zumindest keine Funktionalität. Wenn man die linke Ctrl-, Windows- oder Alt-Taste in Verbindung mit Ebene 4 oder 6 benutzen will, muss man nur darauf achten, dass Ctrl, Windows oder Alt vor Mod4 gedrückt werden. Dabei wird allenfalls Alt in Verbindung mit den Steuertasten auf Ebene 4 lästig. Man würde gerne Mod4 gedrückt halten und Steuertasten mal ohne, mal mit Alt drücken. Das geht so nicht mehr. Dieses Ärgernis besteht nur, weil Neo keine rechte Alt-Taste anbietet. Wenn man ein zusätzliches Alt zum Beispiel auf die rechte Windows- oder Menü-Taste legt, ist auch das erledigt. Andreas
Re: [Neo] Windowstasten per Xmodmap zu AltGr (Mod4) machen?
Kann man diese Windowstasten per Xmodmap zu was anderem machen? Ja. Zum Beispiel zu einer rechten Mod4-Taste? Das geht nur mit der rechten Windowstaste, nicht mit der linken. Andreas P.S. Je nach Ausgangsbelegung kannst du etwas in der Art benutzen: keysym Super_L = ISO_Level5_Shift keysym Super_R = ISO_Level5_Shift clear mod4 Übrigens, xkeyboard-config hat fixfertige Optionen dafür.
[Neo] Control-X/C/V mit alternativen Belegungen (was: AdNW getestet – bleibe doch bei Neo)
Mir gefällt aktuell die zweite Variante besser, weil sie in jeder Situation gut zu erreichen ist. Wenn man beide Hände auf der Tastatur hat, bietet sich Z/H/N mit dem rechten Zeigefinger an (und man kann auf der Grundposition bleiben). Wenn die rechte Hand auf der Maus liegt, kommt man aber auch mit dem linken Zeigefinger noch einigermaßen bequem dran. Nur Mod4 ist auf der linken Seite etwas klein. Ich denke aber man gewöhnt sich dran (oder verwendet Mod4 rechts). Diese Variante hat den Nachteil, dass die Bedienung mit einer Hand eine ungeteilte Tastatur voraussetzt. Ansonsten finde ich diese Lösung einleuchtend. Dass ein paar Symbole verdrängt werden, scheint mir akzeptabel; ¡ und ¿ passen ohnehin weder zum Zahlenblock noch zum Navigationsblock. Auf der anderen Seite lässt die erste Variante die 4. Ebene intakt. Allerdings finde ich das Moment nicht so schön zu tippen, weil man die Grundposition verlassen muss (Qwertz S/D/F kollidiert mit Windows-Shortcuts) und mit dem kleinen Finger so weit runter muss. Diese Variante ist nicht schwerer zu tippen als das Original QWERTZ-Control-X/C/V, oder? Noch mehr Varianten: - Auf Ebene 4 sind Tab und 4 noch unbelegt. Man könnte eine Position mit Control-C, die andere mit Control-V belegen. Control-X kann man sowohl mit «Aus der Neo-Welt» als auch mit Arnes neuer Belegung ohne Tricks mit links eingeben. - Auf der linken Hälfte von Ebene 4 gibt es Symbole, auf die man vielleicht zugunsten von Steuerfunktionen verzichten würde: ª º №. - Man legt die Control-Codes auf die Umlaute; zum Beispiel könne die Eingabe von Control-ö ein Control-C an die Anwendung schicken. Das setzt voraus, dass keine Anwendung Control-Umlaut als Kürzel verwendet. Dieser Vorschlag war schon vor einem Jahr auf dem Tisch, hat aber keine Resonanz gefunden. - Man tippt Control-C und Control-V mit Control-T1 und Alt-T1. Wenn Control und Alt mit dem Daumen gedrückt wird ist das schmerzfrei, die Hand muss man aber schon bewegen. Konflikte mit Kürzeln in Anwendungen sind nicht zu befürchten. - Man könnte spezielle Sequenzen benutzen, um die Control-Codes einzugeben. Zum Beispiel könnte Drücken, Loslassen und wieder drücken von Control (ohne irgendetwas dazwischen) ein Control-C eingeben, Drücken und Loslassen von Alt gefolgt von Drücken von Control ein Control-V. Unter X braucht man dazu ein Zusatzprogrämmchen. Ich habe etwas in der Art im Einsatz. Es wäre gut, Rückmeldung zu dem Thema zu bekommen. Die Mausschubser lassen sich einfach nicht damit abspeisen, dass sie im Vergleich zu den vi-Usern nichts zu klagen haben. Wir brauchen eine Lösung. Andreas
Re: [Neo] AdNW getestet – bleibe doch bei Neo
Kopieren, ausschneiden und einfügen mit Strg + c, x und v sind, wenn man die rechte Hand an der Maus hat, sehr schlecht zu erreichen. Berücksichtigt das bitte für ein Neo 3. Mit meinem XKB-Treiber kann man diese Funktionen mit Mod4 plus rechter Control/Windows/Alt-Taste erreichen (das war eine Idee eines Mitglieds der Nordtast-Liste). Auf Windows kann das bestimmt auch so machen. Es gibt keinen Grund, wegen dieser Tastenkombinationen Kompromisse bei der Lage der Buchstaben einzugehen. Andreas
Re: [Neo] Tastenbelegung mit xmodmap ändern
Okay, dann war das mein Fehler. Ich habe gedacht, xmodmap ist xmodmap und so wie ich die QWERTZ-Belegung ändere, so ändere ich auch mein NEO über xmodmap. Aber das ist wohl nicht der Fall?! Was du bei xmodmap bekommst, hängt davon ab, welche Belegung du damit überschreibst, insbesondere davon, wieviele Ebenen jede Taste hat und wie diese Ebenen xkb-technisch realisert sind. Das ist der Grund dafür, dass man erst ein litauischen Layout einstellen soll, bevor man die Neo-xmodmap läd; das litauische Layout hat die erforderlichen Eigenschaften. Das funktioniert leider auch nicht besser als wenn ich (wie in meinem Post schon erwähnt) nur 8 Zeichen/Ebenen definiere. Die Ausgabe ändert sich kein Stück. Zwei Vorschläge: 1. Lass dir mit xmodmap -pke meine.xmodmap die aktuelle Belegung in das file meine.xmodmap ausgeben, editiere es nach Geschmack, und lade es mit xmodmap meine.xmodmap zurück. 2. Lass dir mit xkbcomp :0 meine.xkb die aktuelle Belegung in das file meine.xkb ausgeben, editiere es nach Geschmack, und lade es mit xkbcomp meine.xkb :0 zurück. Die zweite Variante ist bevorzugt und funktioniert sicher, bei der ersten habe ich nur einen ganz einfachen Test gemacht. Andreas
Re: [Neo] [NordTast] AdNW in NeoVars
Kann ich deine Mail mit der Beschreibung der Parameter hier posten? Die finde ich nämlich klasse! Ja, klar. Andreas
Re: [Neo] [NordTast] AdNW in NeoVars
Ich erspare mir hier die Vorstellung von AdNW, das sollen andere Leute tun, die sich mehr um seine Entstehung bemüht haben als ich. «Aus der Neo-Welt» wurde auf der Neo-Liste schon vorgestellt, nur ohne den Namen. Es ist die erste der Belegungen, die ich hier gezeigt habe: http://lists.neo-layout.org/pipermail/diskussion/2010-May/017417.html Wer den Thread zurückverfolgt wird ungefähr wissen, wie es zu dieser Belegung gekommen ist. Eine Implementierung für Systeme, die X benutzen, ist hier: http://wettstae.home.solnet.ch/neo.sh.gz Das ist ein ksh-Skript, das ein xkb-File erzeugt. Eine kurze Beschreibung bekommt man mit ./neo.sh -h. Das Skript unterstützt auch Neo2 und NordTast (Wer schon länger die Neo-Liste mitliest: Das Skript ist die aktuelle Version meines «monolithischen Treibers»). Gegenüber naiven Anpassungen der offiziellen Neo-Treiber hat neo.sh den Vorteil, dass es sich um die Probleme mit Ebene 4 herummogelt. Leider funktioniert das nicht auf allen Systemen. Probleme habe ich vor allem auf modernen Systemen beobachtet, Ebene 4 ist dort weitgehend lahmgelegt. Für solche Systemen kann man die Option -n benutzen, verliert dann aber einige Neo-Spezialitäten (siehe ./neo.sh -h). Ich habe Anlass zu vermuten, dass die Probleme bei X-Servern ab Version 1.9.0.901 behoben sein könnten; ein Satz in den Release-Notes tönt sehr danach. Über Rückmeldung diesbezüglich wäre ich dankbar, ich selbst habe noch eine ältere X-Server-Version. Andreas
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
Ich würde gerne mal wieder schauen, ob ich nicht einen ein-tag-korpus erstellen kann. Mit dem Prog von Klausler kann ich zumindest mein Programmieren mit emacs einfangen. Du meist mit einer Art keylogger? Mit der XRecord-Extension kann man einen schreiben, der jedes Tastenevent (leider auch solche, die durch autorepeat erzeugt werden) mitbekommt, nicht nur solche in Emacs. Leider müsste man mühsam die aktuelle Ebene und daraus die eingegeben Zeichen rekonstruieren, der Modifikatorstatus wird nämlich nicht mitgeliefert. Bei Bedarf kann ich mich näher dazu auslassen. Wenn du an einem Tag soviel tippst, dass das Ergebnis statistisch brauchbar ist, bist du wirklich schnell. Und wenn es darin nicht vor Tippfehlern wimmelt bist du sehr sorgfältig. Und wenn das Ganze dann noch irgendwie repräsentativ ist, bist du sehr durchschnittlich, und das passt nicht zu «sehr schnell» und «sehr sorgfältig». Ich bin von meiner Ansicht abgerückt. Heute behaupte ich, man müsste die u-ShiftL-Kollision normal und die von u-b Kollision schwächer werten, weil zwischen u und b ja noch eine Taste (ShiftL) gedrückt wird. Das ist ein Spezialfall einer «indirekten Kollision»: Einer Kollision zwischen Tasten, zwischen denen eine weitere Taste mit der anderen Hand oder mit dem Daumen getippt wird. Mein aktuelles Lieblingsthema. Könntest du mir das erklären? Am besten direkt auf der Liste :) Es geht um Sequenzen von drei Tasten, von denen die erste und die letzte auf derselben Hand liegen, die mittlere aber nicht. Solche Sequenzen mit zwei Handwechseln sind schnell zu tippen. Daher kann man sich vorstellen, dass die Position der ersten Taste einen Einfluss darauf hat, wie leicht oder schnell die dritte zu tippen ist. Die einfachste Art, das in eine Bewertung einfliessen zu lassen, ist dem Trigramm dieselbe Bewertung zu geben wie dem Bigramm aus erstem und letzten Zeichen, multipliziert mit einem Faktor kleiner eins. Der Faktor könnte vom Tippaufwand der mittleren Taste abhängen: Je besser oder schneller die mittlere Taste getippt werden kann, desto grösser der Faktor. Das ist aber vermutlich nur eine unnötige Komplikation. Sequenzen wie bei der Eingabe von «uB», wenn u und b auf der selben Hand sind, sind ein Spezialfall davon, wobei Shift die mittlere Taste im Tasten-Trigramm ist. «Bu» ist ähnlich, aber nicht ganz gleich: Die erste Taste ist Shift und die mittlere b. Allerdings muss Shift gehalten werden bis b gedrückt ist, daher beeinflusst Shift das u stärker als die erste die dritte Taste in normalen Trigrammen. Der Vorfaktor vor dem Bigrammgewicht sollte daher grösser sein, aber nach wie vor kleiner eins. Bei Trigrammen ohne Handwechsel kann die erste Taste natürlich auch bestimmen, wie gut die dritte zu tippen ist. Die Situation ist aber viel verwickelter, da die mittlere Taste eine grosse Rolle spielt. Wenn man Trigramme mit zwei Handwechseln auf die beschriebene Art in die Bewertung einbaut, kann unter Umständen (das hängt von anderen den Details des Bewertungsschemas ab) etwas Interessantes passieren: Die Vokale bei der optimalen Tastatur verteilen sich auf beide Seiten und man hat nur noch «wenige» Handwechsel (vielleicht bei 55% aller Bigramme). In dieser Hinsicht ähneln diese Belegungen stärker modernen Belegungen wie Colemak und Arensito als Dvorak. Ich habe allerdings noch kein effizientes System im Kopf, um das sauber zu machen. Wie hast du das implementiert? Das kannst du im Optimierer sehen, in den Funktionen «aufwand» und «diff_aufwand», siehe http://wettstae.home.solnet.ch/opt.c (Falls jemand damit rumspielen will, ich habe das auch zusammen im Paket mit meinen Korpora, in http://wettstae.home.solnet.ch/Optimierer.tar.gz). Die Kosten von Tasten (nicht Zeichen) kann ich ja eigentlich zwischencachen (die bleiben bei dem Layout ja gleich). Mappst du dann einfach die Tastenpositionen und Kosten auf eine Matrix und schreibst die Bigramme in Positionen um? Genau. Jede Taste hat einen Index zwischen 0 und ntaste-1, und zwei solcher Indices geben bezeichnen einen Eintrag in der Matrix mit vorab berechneten Bigrammkosten (Dazu kommen noch zusätzliche Indices für die Behandlung von Shift, aber das ändert nichts am Prinzip). Mit den Bigrammhäufigkeiten ist es genauso, nur sind die Indices nicht Tastennummern, sondern Buchstabennummern, auch sie von 0 bis ntaste-1 nummeriert. Kosten und Häufigkeit finden durch die Belegung, dargestellt durch eine Permutation p der Zahlen 0…ntaste-1, zueinander. Die Bigrammbewertung ist dann eine Summe von K(i,j)*H(p(i),p(j)) über alle i,j. Ein- und Trigramme sind analog. Andreas
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
Sorry, ich habe das gestern versehentlich direkt an Arne geschickt. Jetzt aber richtig: Für Leute, deren Job Kernelprogrammierung ist, könnte sich die Optimierung lohnen. Auch wenn die Programmiersprache oder sogar das Programmierprojekt feststeht, man müsste noch wissen ob emacs, vi oder Eclipse benutzt wird. Was im Korpus steht ist nicht alles auch getippt worden. Tools nehmen unter Umständen einiges ab. Genauso für Leute, die viel Griechisch oder mathematische Symbole schreiben. Die bevorzugten Symbole sind in unterschiedlichen Disziplinen verschieden. Ich glaube nicht, dass sich ein repräsentativer Korpus für mathematische Symbole finden lässt. Ausserdem, wenn man annimmt, dass die lateinischen und griechischen Buchstaben aneinander kleben (a am α und so weiter) müsste man normale Texte und Formeln gegeneinander abwiegen. Dafür brauchen wir „nur“ einen korrekten Korpus :) Es geht schließlich darum, das tippen zu können, was im Korpus steht. Ja, man braucht einen hinreichend korrekten Korpus, weil nur ein korrekter Korpus repräsentiert, was man tippen will. Ich habe mir tatsächlich schon überlegt, meinen (3MB) Korpus zu bearbeiten, aber das ist viel Arbeit mit sehr begrenztem Nutzen. Ich fände es grundlegend noch schöner, die feste Zuordnung der Finger auf die Tasten aufzulösen. Zum Beispiel hat mir eine Bekannte erzählt, dass sie im Tippkurs gelernt hat, dass bei Neo „sh“ das „s“ vom Zeigefinger und das „h“ vom Mittelfinger gedrückt werden sollte. Das läuft darauf hinaus, dass derselbe Text bei derselben Belegung mit unterschiedlichen Bewegungen getippt werden kann. Schwierig zu bewerten und schwierig zu lernen. Es könnte aber wirklich die Tippeffizienz steigern. Gerade auf der linken Tastaturhälfte könnte man einiges mit den «falschen» Fingern machen. Das ist das Bigrammgewicht Mod6R-Mod6L. Hier müsste man allerdings noch berücksichtigen, dass Mod4R ausnahmsweise vom Ringfinger getippt wird. Du meinst M4L, oder? Ja, richtig. Um das hier zu berücksichtigen, müsste die Handverschiebung von M3L-M4L erhalten bleiben, d.h. wir müssten komplett auf Trigramme wechseln (teuer). Da braucht man noch keine Trigramme. Die Idee mit virtuellen Tasten ist ja gerade, das gleichzeitige Drücken von Mod3L und Mod4 wie einen einzigen Tastendruck zu behandeln. Ein Gedanke, den ich noch hatte ist, bei uB die Fingerkollision von u und shift-L stärker zu werten als bei Bu, weil shift etwas früher gedrückt und gelöst wird als b. …ich glaube allerdings, die Idee ist auch von dir ;) Ich bin von meiner Ansicht abgerückt. Heute behaupte ich, man müsste die u-ShiftL-Kollision normal und die von u-b Kollision schwächer werten, weil zwischen u und b ja noch eine Taste (ShiftL) gedrückt wird. Das ist ein Spezialfall einer «indirekten Kollision»: Einer Kollision zwischen Tasten, zwischen denen eine weitere Taste mit der anderen Hand oder mit dem Daumen getippt wird. Mein aktuelles Lieblingsthema. In den Bigrammen tut eine zusätzliche if-Abfrage nicht sehr weh. In den Trigrammen wäre das etwas anderes… :) Auf die Gefahr hin, dir auf die Nerven zu fallen: Vielleicht solltest du die N-gramm-Strafpunkte und -häufigkeiten in simplen Matrizen tabellieren. Dann ist die Auswertung im wesentlichen ein Skalarprodukt zwischen Strafpunkten und Häufigkeiten, und sowas rechnet sich gut und schnell, auch wenn in den Matrizen viele Nullen stehen die man unnütz abarbeitet. Ich mache das so ähnlich, und kann auch mit Trigrammen einige hundert lokal optimale Tastaturen pro Minute berechnen. Es würde mich wundern wenn es bei den numerischen Erweiterungen für Python nicht etwas gäbe, mit dem man zumindest bis auf eine Grössenordnung daran heran kommt. Andreas
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
Bisher wird allerdings nur shift berücksichtigt (bzw. Großbuchstaben), daher dürften wir noch ein paar Kollisionen auf dem kleinen Finger verpassen (bei Sonderzeichen auf der dritten oder höheren Ebenen). Ich arbeite gerade daran, das zu ändern. Schau die Zeichenhäufigkeiten im Korpus an. Für Englisch noch könnte es sich lohnen, den Apostrophen mitzunehmen, da er wegen Genitiv-s einen bevorzugten Kollisionsgegner hat. Ansonsten zweifle ich, dass es sich rentiert, weitere Zeichen mitzunehmen. Zudem müsste man erst die Typographie im Korpus verifizieren: Was ist wirklich ein Bindestrich, was sollte eigentlich ein Gedankenstrich sein? Was sollte anstelle der geraden doppelten ASCII-Anführungszeichen stehen, was anstelle des geraden ASCII-Apostrophen? Konkret ist meine Frage, ob das hier die korrekte Aufteilung von Ψ∃ ist: Wie tippst du Mod3L+Mod4L? Mit den offiziellen Neo-Positionen würde ich dazu Klein- und Ringfinger nehmen, für Mod3L und Mod4L einzeln aber jeweils den kleinen Finger. Man könnte Modifierpaare wie virtuelle Tasten behandeln, die von einem virtuellen Finger bedient werden. Im Beispiel oben besteht der virtuelle Finger aus linkem Klein- und Ringfinger. Für die viruelle Taste überlegt man sich dann die Strafpunkte in Kombination mit allen anderer realen und virtuellen Tasten. Die gedankliche Einführung der virtuellen Taste führt noch nicht zu einer Herleitung der Bewertung aus bekannten Bewertungen, denn das geht eben nicht, weil Modifierkombinationen anders getippt werden als Modifier einzeln. Es ist lediglich eine nützliche Abstraktion, vermutlich auch nett zum implementieren, zumindest in meinem Optimierer wäre es so. # Die Modifier beider Zeichen miteinander '⇩⇙', M3L + M4R '⇩⇘', M3L + M3R '⇚⇙', M4L + M4R '⇚⇘', M4L + M3R Das ist das Bigrammgewicht Mod6R-Mod6L. Hier müsste man alledings noch berücksichtigen, dass Mod4R ausnahmsweise vom Ringfinger getippt wird. # Die Modifier mit dem anderen Modifier der Taste # sortiert – sollte das in beide Richtungen gehen, also 0.5*(m3-m4, m4-m3)? '⇩⇚', M3L + M4L '⇘⇙', M3R + M4R Das sind die Einzeltastengewichte für Mod6L und Mod6R. Die Summe der realen Einzeltastengewichte ist wäre ein guter Ausgangspunkt, eine Reduktion dafür, dass beide Tasten in mit einer Handbewegung erreicht werden, wäre zu überlegen. # Die Modifier mit den dazugehörigen Grundtasten '⇩h', shiftL + h '⇚h', M4L + h '⇙e', M4R + e '⇘e', M3R + e # Die Modifier mit der jeweils anderen Grundtasten '⇩e', shiftL + e '⇚e', M4L + e 'h⇙', h + M4R 'h⇘', h + M3R Mod3L, nicht shiftL, oder? Das sind Bigrammgewichte Mod6L mit Buchstabentaste und Buchstabentaste mit Mod6R mit Buchstabentasten. Auch hier müsste man noch bedenken, dass Mod4L irregulär getippt wird. # Die Grundtasten (auf Ebene 1) 'he' Das wenigstens ist klar. Aber, wie gesagt, schon Ebene 3 lohnt sich kaum zu berücksichtigen, Ebene 5 und 6 kannst du für die Optimierung vergessen. Andreas
Re: [Neo] [Linux] StumpWM erkennt ISO_Level3_Shift nicht als Modifier
Mein Problem steht schon im Betreff. Was habe ich versucht, um das mal zu lösen? http://www.mail-archive.com/stumpwm-de...@nongnu.org/msg00439.html behauptet, dass dein Problem vor über zwei Jahren behoben wurde. Im Gegensatz zu Eriks Kristallkugel sagt meine, dass du xkbmap verwendest. Also, falls das Problem auch mit einem aktuellen StumpWM noch existiert, probiere mal xmodmap, die implementiert nämlich die Ebene 3 anders (nicht per Level- sondern per Gruppenumschaltung). Allenfalls könntest du den monolithischer Treibergenerator¹ mit Option -szd ausprobieren. Andreas ¹http://wettstae.home.solnet.ch/neo.sh.gz
Re: [Neo] Nachbarstrafe (war Vrijbuiter usw)
Pfeif einmal auf die Einwärtsbewegungen oder halte Lagepunkte/Fingerwiederholung/Auswärtsbewegungsstrafe in etwa 150/35/10, Unsere Bewertungskriterien sind verschieden, daher kann ich diese Empfehlung nicht direkt übertragen. Qualitativ habe ich gesehen, dass der Einfluss der Auswärtsstrafpunkte sehr abrupt einsetzt. halte E und N auf die Mittelfinger, Ich fühle mich nicht befugt, dem Optimierer solche Vorschriften zu machen. Ich weiss zwar nicht, ob Einwärtsbewegungen wirklich besser sind als Auswärtsbewegungen. Aber allmählich ist für mich der Zeitpunkt gekommen, eine von meinen Tastaturen auszuprobieren statt nur zu theoretisieren. Dazu bietet es sich an, eine Tastatur mit klarem Charakter zu wählen, vielleicht gelingt es mir ja dann wider Erwarten, diesen Charakter zu erspüren und zu bewerten. In meinem Fall ist ein Teil dieses Charakters die Dominanz von Einwärtsbewegungen. Konkret probiere ich diese Tastatur aus: links rechts 1.096 Kollisionen 2.833 Shift-Kollisionen ob 7.4 12.2 kuü.ä vgcljf70.872 Handwechsel28.234 Shift-Handwechsel mi 36.2 34.5 hieao dtrnsß15.448 Einwärts 67.797 Shift-Einwärtsun 5.9 10.1 xyö,q bpwmz 10.218 Auswärts 12.033 benachbart sum 49.6 56.8 Finger 10.2 11.4 16.8 11.1 | 17.8 11.6 16.0 11.4 Shift 4.5 1.8 Die Bewertung oben ist mit Karls Bearbeitung des Leipziger Korpus gemacht und fällt mässig aus; die eigentliche Optimierung habe ich mit einem 1:1 gemischten deutsch/englischen Korpus gemacht, und das hat natürlich seinen Preis für’s Deutsche. Auf den Leipziger Korpus optimiert bekomme ich mit denselben Bewertungskriterien: 1.112 Kollisionen 1.083 Shift-Kollisionen ob 7.1 11.8 kzo.ü xhlcjv67.154 Handwechsel28.811 Shift-Handwechsel mi 35.9 34.4 gaeiu dsrntq16.770 Einwärts 68.875 Shift-Einwärtsun 6.4 10.8 ßäö,y bfwmp 12.598 Auswärts 13.090 benachbart sum 49.4 56.9 Finger 8.9 7.5 18.8 14.1 | 18.9 12.5 15.0 10.4 Shift 4.3 2.0 Tja, die Shift-Kollisionen… Andreas
Re: [Neo] Weiter mit Vrijbuiter
Ich habe andere Einzeltastengewichte probiert, und zwar: 2 1 1 1 2 2 1 1 1 2 3 1 0 0 0 1 1 0 0 0 1 3 4 3 3 3 4 4 3 3 3 4 Das erinnert mich daran, dass ich das e meistens auf den Ringfinger bekomme, seit ich das Einzeltastengewicht in der oberen Zeile für den Ringfinger grösser ansetze als für den Mittelfinger. Solange die Werte gleich waren war das üblicherweise nicht so. Ich weiß nicht, wie viel Einwärtsbewegungen, man schafft, aber ich schätze, dass mehr als 2/3 wohl nicht drin ist, man wird wohl meistens bei 60% oder so landen. Dvorak auf Englisch hat ein:aus = 10:15, Vrijbuiter 10:18. Auf Deutsch. Ich habe mit den Strafpunkten rumgespielt. Tatsächlich ist man irgendwo bei 2/3 am Anschlag. Ich habe auch nie Handwechsel gesehen, der viel über 70% geht. Hier hat man also wahrscheinlich ein Optimum erreicht. Auch das kann ich bestätigen. Mit Karls überarbeitetem Leipziger Korpus komme ich bis 71,8%. Mir schwebt so etwas vor, wie Strafpunkte zu vergeben bei allen Bigrammen, die aus Kleinfinger und Ringfinger (viel Strafe) oder Ringfinger und Mittelfinger (wenig Strafe) bestehen. Bigramme aus Zeige- und Mittelfinger könnte man ignorieren. Dann den Optimierer laufen lassen mit starker Strafe für diese Dinge, und dabei alles andere belassen, wie es jetzt ist. Das gibt kaum zusätzliche Rechenaufwand. Ich habe damit experimentiert, aber vereinfachend Stafpunkte für alle benachbarten Fingereinsätze gegeben. Für den Rechenaufwand ist bei mir alles egal, solange es durch Bigrammstrafpunkte auszudrücken ist; ich habe vereinfacht, weil ich dann allein am Anteil der benachbarten Fingereinsätze den Effekt ablesen kann. Mit deinem differenzierteren Vorgehen müsste man auch den Effekt differenzierter anschauen. Strafpunkte für benachbarte Finger kosten zunächst mal bei den Kollisionen (klar, bei Kollisionen hat man keine benachbarten Finger). Mit meinen sonstigen Kriterien komme ich bis unter 13% ohne grosse Einbussen. Drehe ich die Stafpunkte hoch geht es bis ca. 9% mit ein paar Kollisionen mehr. Zum Vergleich: Dvorak hat 13,6% und NordTast ungefähr 17,1% (alles mit Karls überarbeitetem Leipziger Korpus ausgewertet). Falls die Dvoraksche Magie tatsächlich damit zu tun hat zu vermeiden, benachbarte Finger nacheinander zu benutzen, könnten wir das leicht nachzaubern. Andreas
Re: [Neo] Parameter für den Algorithmus
Ich würde sowieso sehr gerne einmal die Algorithmen der automatischen Optimierer genauer betrachten. Weiß jmd. gerade zufälligerweise wo ich die finde? http://wettstae.home.solnet.ch/opt.c Andreas
Re: [Neo] Vorstellung erweitertetes Standardlayout: DeutschlandPlus
Ich brauche die Klammern oben recht häufig und komme gut damit klar. Findet ihr die einfache Erklärbarkeit (alles aufgedruckte auf den Tasten stimmt noch) den Preis nicht wert? Das bei QWERTZ alles funktionieren soll wie gehabt ist dein Ausgangspunkt. Das hindert dich aber nicht daran für die Klammern bessere, alternative Positionen zu suchen … Wenn ich das so überlege, könnte man auch die einfache Regel so lassen und den Rest links noch sinnvoll füllen. … und die linke Hälfte wäre zum Beispiel geeignet. Klammern tippt man üblicherweise nicht in längeren Sequenzen, dann ist der Einhand-Grätschgiff akzeptabel. Andreas
Re: [Neo] Ein Knaller! (war: 1-, 2-, 3-gramme erstellen unter Linux)
Bei mir kam im Test das hier raus: $ ./check_neo.py -v --check-string jäo.ü khclfv teaiu gdnrsß xqö,y bpmwz # 1.78690591274 % finger repeats in file 2gramme.txt Merkwürdig, die Fingerwiederholungen passen nicht zu dem, was ich bekomme. Du zählst deutlich mehr als ich. Umso merkwürdiger, als wir für NordTast ungefähr dasselbe bekommen (wenn ich die Shift-Kollisionen bei den Kollisionen mitzähle). öckäy zhmlß, atieo dsnru. xpfüq bgvwj # 1.74869097499 % finger repeats in file 2gramme.txt Und hier sind es ungefähr gleichviele, aber nur, wenn ich Shift-Kollisionen nicht mitzähle. Da muss ich mir wohl meine Auswertung nochmal genauer anschauen. Andreas
Re: [Neo] Anleitung: 1-, 2-, 3-gramme erstellen unter Linux
*neugierig* Um was ging es bei den gerade im Sourcecode stehenden speziellen Kriterien? Entschuldige, «speziell» war nicht das rechte Wort. Ich bin einfach nicht so fleissig wie Arne, das Feedback aus der Liste einzubauen, und drehe ab und an den Kriterien. In zwei Wochen käme wahrscheinlich ein anderes Optimum raus, das ist, was ich sagen wollte. Also sollte es zudem darauf hinaus laufen, weitere Korpora aus verschiedenen Gebieten für unsere Zwecke aufzubereiten. Vielleicht. Ich habe mir zum Beispiel einen kleinen (600k) Korpus aus einer Archiv-DVD der Computerzeitschrift c't extrahiert (auch in neuer Rechtschreibung). In dem kommt dann zum Beispiel, im Gegensatz zum Leipziger Korpus, das Komma häufiger vor als der Punkt. Aber alles in allem sind die Auswirkungen auf das Ergebnis moderat. Wenn man einen sehr kleinen Korpus mit einem sehr grossen mischt und so gewichtet, dass beide ungefähr gleich in die Optimierung eingehen, bestimmt der kleine Korpus leider den statistischen Fehler. Es dürfte schwer sein, Korpusse aus anderen Gebieten zu finden, die so gross wie der Leipziger Korpus sind (von jemandem, der sie entrümpelt, ganz zu schweigen). Im übrigen würde ich sowieso nach einem 1:1 gemischt deutsch-englischen Korpus optimieren. Das entspricht viel mehr meinen Anforderungen, und da bin ich sicher nicht alleine. Andreas
Re: [Neo] Fremdsprachliche Korpusse
Ich finde, dass das eine sehr gute und richtige Anregung ist! Natürlich können wir nicht auf alle lateinischen Sprachen gleichzeitig optimieren (man könnte schon, nur würde dabei halt eine ›alles etwas aber nichts richtig‹ Tastatur herauskommen), Aber gerade wenn sich die verschiedenen computergenerierten Tastaturen nur noch geringfügig voneinander bezüglich des Deutschen unterscheiden, wäre eine zusätzliche Analyse bezüglich der ›Kompatibilität‹ mit anderen Sprachen – wie Mœsi bereits andeutete, ist Englisch hier wohl die Wichtigste – schon sehr interessant. Ich bin für eine 1:1-Mischung Deutsch und Englisch. Die Frage ist: Wo kriegen wir einen englischen Korpus her? Kennt da jemand Einen? Die Leipziger haben einige Sprachen auf Lager, auch Englisch. Ansonsten gibt es Project Gutenberg und diesen hier: http://americannationalcorpus.org/# Andreas
Re: [Neo] Ein Knaller! (war: 1-, 2-, 3-gramme erstellen unter Linux)
Was kriegst du bei dem Layout raus? Mit dem neuen Leipziger Korpus gibt es für mein Layout: 0.832 Kollisionen 4.225 Shift-Kollisionen und für dein derzeit optimales Layout: 1.711 Kollisionen15.880 Shift-Kollisionen Andreas
Re: [Neo] Ein Knaller!
CH und CK in ungewohnter Einhandlage. C rechts ist überhaupt schon lange nicht mehr auf der Liste gestanden. Die Einhandlage von CH und CK kann man konkret auf ein Optimierungskriterium zurückführen: Wenn ein Bigramm auf der oberen oder unteren Zeile derselben Hand getippt wird, wird der Tippaufwand des zweiten Zeichens reduziert, da die Bewegung aus der Grundstellung schon mit dem ersten Zeichen des Bigramms aufgeführt wird, zumindest teilweise. Jungs, ran an die Arbeit. Probiert diese aus! Bin schon dabei! Mein Beitrag dazu der Anhang: Ich bekomme fast ein schlechtes Gewissen. Andreas
Re: [Neo] Fremdsprachliche Korpusse
Kann vielleicht mal jemand der ›Auswerter‹ so nett sein und Neo 2 und NordTast in Bezug auf einen rein englischen Korpus analysieren? Mit dem englischen Leipziger Korpus bekomme ich: Neo2 321.849 Gesamtaufwand 194.512 Lageaufwand links rechts 8.935 Kollisionen 6.235 Shift-Kollisionen ob 10.1 9.2 xvlcw khgfqß59.876 Handwechsel41.029 Shift-Handwechsel mi 37.3 34.5 uiaeo snrtdy13.308 Einwärts 49.277 Shift-Einwärtsun 4.4 8.2 üöäpz bm,.j 15.329 Auswärts3.459 Shift-Auswärts sum 51.7 51.9 Finger 4.9 8.3 12.3 26.2 | 23.0 9.4 12.1 7.3 Shift 2.1 1.5 NordTast 250.312 Gesamtaufwand 197.353 Lageaufwand links rechts 1.619 Kollisionen14.049 Shift-Kollisionen ob 13.5 11.5 äuobp kglmfx66.621 Handwechsel31.151 Shift-Handwechsel mi 39.4 28.6 aietc hdnrsß14.034 Einwärts 51.612 Shift-Einwärtsun 4.3 6.3 .,üöq yzwvj 15.174 Auswärts3.188 Shift-Auswärts sum 57.2 46.4 Finger 11.4 11.0 19.1 15.7 | 12.6 12.7 10.0 11.2 Shift 1.8 1.8 Andreas
Re: [Neo] Anleitung: 1-, 2-, 3-gramme erstellen unter Linux
Hallo Karl, im Winter habe ich die für uns zugrunde gelegte Datei des Leipziger Korpus überarbeitet. Über 300 MB Rohdaten, eine unglaubliche Arbeit. Vielen Dank. Für unsere Zwecke sind diese aktuell kreierten Daten sicher besser zu gebrauchen, als der pure - zu zeitungslastige - Leipziger Korpus. Der Inhalt kommt aber doch nach wie vor komplett vom Leipziger Korpus, oder hast du noch andere Quellen aufgetan? Andreas
Re: [Neo] Probleme mit Neo und KDE
Mich nervt im Übrigen auch, dass man die STRG-Kombinationen nicht richtig verwenden kann, wenn die Neo-xkbmap nicht das primäre Layout ist. Ich habe in den monolithischen Treibergenerator eine Option (-ad) eingebaut, mit der man die alphabetischen Tasten per Redirect für alle Layouts immer auf denselben keycode umbiegt, in der Hoffnung, dass das solche Probleme umgeht. Da ich aber KDE nicht benutze habe ich es nie getestet. Vielleicht probiert es ja mal jemand: http://wettstae.home.solnet.ch/neo.sh.gz Zu benutzen in der Art ./neo.sh -b 21 -ad test.xkb xkbcomp test :0 siehe auch die Hilfeoption -h. Achtung: man sollt vor Auführen von xkbcomp sicherstellen, dass man mit der Maus die vorige Belegung wieder einstellen kann; aus nicht bekannten Ursachen werden die Redirects manchmal nicht übernommen, und dann ist das Layout ernsthaft zerschossen. Oder ist das ein generisches Problem des Tastaturtreibers? Ich vermute, das ist ein Fehler von KDE (oder eins tiefer, von Qt). Andreas
Re: [Neo] Anleitung: 1-, 2-, 3-gramme erstellen unter Linux
Mich interessiert, ob ein Optimierungsprogramm damit tatsächlich nennenswert andere Ergebnisse liefern wird, als bei auf alter Rechtschreibung. Ich habe meinen Optimierer mit beiden Korpussen je 25000 Runden laufen lassen. Mit einem Teil (ca 100k Zeilen) des alten Korpus (zuerst Korpusstatistik, dann die beste gefundene Tastatur): aA 5.296/0.474 bB 1.582/0.447 cC 2.582/0.112 dD 4.135/0.558 eE 15.535/0.345 fF 1.415/0.295 gG 2.661/0.300 hH 3.957/0.225 iI 7.505/0.189 jJ 0.122/0.148 kK 1.146/0.320 lL 3.484/0.192 mM 2.247/0.419 nN 9.546/0.166 oO 2.580/0.084 pP 0.691/0.312 qQ 0.014/0.012 rR 7.229/0.226 sS 5.500/0.662 tT 5.963/0.227 uU 3.462/0.176 vV 0.688/0.228 wW 1.107/0.288 xX 0.052/0.002 yY 0.101/0.006 zZ 1.070/0.140 äÄ 0.566/0.008 öÖ 0.247/0.010 üÜ 0.647/0.017 .. 1.106/0.000 ,, 0.951/0.000 ßß 0.230/0.000 15.582/0.000 Großbuchstaben:6.585 % Mehrfachanschläge: 1.680 % 234.164 Gesamtaufwand 195.430 Lageaufwand links rechts 0.857 Kollisionen 4.438 Shift-Kollisionen ob 5.3 14.6 jäo.ü khclfv68.646 Handwechsel25.610 Shift-Handwechsel mi 39.2 31.2 teaiu gdnrsß18.230 Einwärts 67.967 Shift-Einwärtsun 6.3 10.0 xqö,y bpmwz 9.979 Auswärts1.984 Shift-Auswärts sum 50.7 55.9 Finger 11.4 16.5 8.7 14.2 | 16.3 15.1 12.5 11.9 Shift 4.9 1.7 Mit dem neuen: aA 5.299/0.461 bB 1.583/0.437 cC 2.591/0.098 dD 4.146/0.527 eE 15.565/0.346 fF 1.425/0.286 gG 2.663/0.287 hH 3.967/0.221 iI 7.509/0.181 jJ 0.121/0.148 kK 1.136/0.315 lL 3.489/0.184 mM 2.245/0.397 nN 9.543/0.158 oO 2.598/0.081 pP 0.691/0.301 qQ 0.014/0.012 rR 7.253/0.218 sS 5.645/0.636 tT 5.992/0.216 uU 3.480/0.152 vV 0.689/0.220 wW 1.114/0.282 xX 0.052/0.002 yY 0.100/0.006 zZ 1.072/0.136 äÄ 0.566/0.008 öÖ 0.249/0.009 üÜ 0.642/0.017 .. 1.104/0.000 ,, 0.954/0.000 ßß 0.155/0.000 16.427/0.000 Großbuchstaben:6.344 % Mehrfachanschläge: 1.713 % 231.510 Gesamtaufwand 193.461 Lageaufwand links rechts 0.832 Kollisionen 4.225 Shift-Kollisionen ob 5.3 14.6 jäo.ü khclfv68.637 Handwechsel24.270 Shift-Handwechsel mi 39.2 31.2 teaiu gdnrsß18.207 Einwärts 70.448 Shift-Einwärtsun 6.1 9.9 xqö,y bpmwz 9.958 Auswärts1.057 Shift-Auswärts sum 50.6 55.8 Finger 11.2 16.5 8.7 14.1 | 16.3 15.0 12.5 11.9 Shift 4.7 1.6 Für die speziellen Kriterien die gerade in meinem Sourcecode stehen kommt also dieselbe Tastatur raus. Das sollte uns nicht enttäuschen, im Gegenteil: Wir sehen, dass nicht jede kleine Variation am Korpus unbedingt das Optimum ändert. Ausserdem ist die Punktzahl mit beiden Korpussen verschieden, und zwar mehr als man durch blosse statistische Variationen erwarten würde. Mit anderen Kriterien könnte das Optimum für die beiden Korpusse durchaus verschieden sein. Andreas
Re: [Neo] Vorstellung erweitertetes Standardlayout: DeutschlandPlus
a) wie findet ihr die Grundidee / Umsetzung? Es ist schön, dass du mit einer einzigen zusätzlichen Modifikatortaste auskommst. Andererseits muss man teilweise zur Zahlenreihe hochgreifen, das ist weniger schön. b) welche wichtigen Funktionen / Zeichen fehlen euch ggf.? Backspace. Da ich nur eine Handseite neu für mich belegen konnte, kann da natürlich nicht alles rein und auch eine Trennung von Zeichen / Funktionen ist da nicht möglich. Ich glaube, dass du durchaus auch die linke Tastaturhälfte mehr belegen könntest, solange du dort Zeichen hinlegst, die wenig in Sequenzen getippt werden. Für einzelne Anschläge ist CapsLock passabel zusammen mit einer weiteren Taste der linken Tastaturhälfte zu drücken. CapsLock hab' ich persönlich übrigens nur noch als Modifier in Nutzung, aber könnte man über das Skript auch in der Originalfunktionalität lassen, so dass bei Gedrückthalten der CapsLock-Taste die Modifier-Funktionalität erreicht wird, aber ein Drücken / Loslassen normal in BESCHEUERTE GROSSSCHREIBUNG umschaltet ;-) Hast du mit dieser Doppelnutzung experimentiert? Mich interessiert, ob das zu vielen versehentlichen Bedienungen führen würde. Wenn nicht, könntest du Backspace auf CapsLock packen. Andreas
Re: [Neo] Test-Korpus[1..n]
So könnte man beispielsweise für jeden Kostenfaktor und für jeden Textkorpus und jedes Layout separate Werte errechnen, die sich längs und quer und somit differenzierter vergleichen lassen. Mit der Dimension «Korpus» hätte man ein einen Ansatzpunkt um herauszufinden, wie gross Bewertungsunterschiede sein müssen, um signifikant zu sein. Ob man durch Vergleiche in der Dimension «Kostenfaktor» etwas lernt ist mir weniger klar. Dazu bräuchte man vielleicht eine qualitative Einschätzung der Layouts (z.B. «geeignet für schnelle Tipper» oder «leicht zu lernen»), die man dann mit den Eigenschaften des Bewertungsschemas in Verbindung bringen müsste. Sinnvoll wäre es, für englischsprachige Texte oder auch beispielsweise Programmiercode bis hin zur aufgezeichneten Programm-Interaktion Textkorpusse zu erstellen und nicht zu versuchen, alles irgendwie in einen fertig gemischten Textkorpus zusammenzurechnen. Ich halte das für sinnvoll. Damit kann man die Erstellung der Korpusse für verschiedene Textgattungen und ihre relative Gewichtung auseinanderhalten. Das ist sicher interessant für alle Selbstoptimierer, die ihre Gewichte selbst wählen wollen, aber keine Lust haben, sich auch eigens einen Korpus zusammenzusuchen. Andreas
Re: [Neo] Nordtast und Neo in meinem Test-Script
Ich glaube die real berücksichtigten Zeichen sind gleich (Kodierung::Klartext[] oder?). Ja, richtig. Könnte es sein, dass Auswärts- oder Einwärtsoptimierung v.a. deswegen funktioniert, weil dann die Tasten eher in eine Richtung angeschlagen werden? Könnte sein. Könnte auch sein dass es garnicht funktioniert und nur eine Reminiszenz an Herrn Dvorak ist. Einwärtsbewegungen gegenüber Auswärtsbewegungen generell zu bevorzugen ist vielleicht nur ein Relikt aus Zeiten der Mechanik, als man zum Tippen noch Kraft gebraucht hat. Auf Ulfs Seiten gibt es einen Abschnitt zu dem Thema. Andreas
Re: [Neo] Nordtast und Neo in meinem Test-Script
Nachtrag: Es ist toll, das in C++ zu sehen! Wie schnell ist dein Skript? Pro Minute kann ich auf einem Kern ungefähr 1 mal eine «lokal optimale» Belegung generieren, in dem Sinne, dass für diese Belegung kein Tausch zweier Tasten noch eine Verbesserung bringt. Andreas
Re: [Neo] Asymmetrisch bewerten
Zuguterletzt nützen wir diese Handverschiebungseffekte und kollektive Fingerbewegungen auch dafür, mehrere Tasten in einer anderen als der Grundreihe ergonomisch hintereinander anzuschlagen – niemand kehrt nach jedem einzelnen Tastendruck mit den Fingern in die Grundposition zurück, wenn an Ort und Stelle noch etwas erledigt werden muss. Um Verschiebungen der Hand (beziehungsweise Mitbewegen benachbarter Finger) zu berücksichtigen, kompensiere ich in meinem Optimierer den Mehraufwand für Tasten abseits der Grundposition teilweise, falls die Taste nach einer Taste mit derselben Hand in derselben Zeile angeschlagen wird. Die Kompensation wird mit negativen Beiträgen zum Bigrammaufwand bewerkstelligt. Der Anteil der Kompensation liegt derzeit bei 1 für Mehrfachanschläge, bei 0.5/Spaltenabstand falls verschiedene Finger beteiligt sind. Man könnte sich sicher noch Besseres überlegen. Andreas
Re: [Neo] Nordtast und Neo in meinem Test-Script
Denkst du, dass wir eine Korrelation zwischen unseren Optimierungs- Parametern finden können, um eine gemeinsame Grundlage zum Optimieren schaffen zu können? Ich glaube schon, die Struktur der Beurteilung ist ja ähnlich: Einzeltastengewichte, Bigrammgewichte, eine quadratische Funktion für die Abweichung der Anschlagshäufigkeit eines Fingers vom Soll. Abweichungen gibt es bei der Zahl der berücksichtigten Tasten und vielleicht bei der Behandlung von Shift. Meine aktuellen Kriterien sind in http://wettstae.home.solnet.ch/opt.c, siehe Funktion Aufwandstabelle::intialisiere_aufwandstabelle_andreas(). Ich glaube aber nicht, dass man sich jetzt schon den Kopf über Koordination verschiedener Optimierer zerbrechen muss. An den Kriterien wird sowieso noch eine ganze Weile rumgepfuscht werden. Die eigentliche Schwierigkeit ist eher, nicht den Überblick über die verschiedenen Argumente zu verlieren, auf denen die Kriterien beruhen. Andreas
Re: [Neo] Nordtast und Neo in meinem Test-Script
Sonderzeichen ignoriere ich, und Großbuchstaben werden zu 0.5*(left_shift+key+right_shift+key), weil in der aktuellen Version beim Das Ergebnis sind bei Nordtast 1,8% Fingerwiederholungen; zumindest nach meiner Berechnungsmethode. Ich komme mit Leipziger Korpus auf 0,86% Kollisionen und 16,62% Shift-Kollionen. Letztere beziehen sich nur auf Anzahl geshifterter Zeichen. Mit ca. 6,6% Großbuchstaben komme ich also total in denselben Bereich wie du. Ulf nimmt Shift-Kollisionen nicht mit. Andreas
Re: [Neo] (Linguistische) Information zur Erstellung des Layouts
Neben dem Korpus ist natürlich interessant was für ein Algorithmus zur Optimierung der Tastatur genommen wird. Derzeit wird vorwiegend der Leipziger Korpus verwendet. Alternativen sind Bücher von Projekt Gutenberg. Ich benutze zum Teil Artikel von der c't-Archiv-DVD. An Algorithmen gibt es evolutionäre (Ulfs Optimierer), solche die Vertauschungen durchführen bis keine mehr eine Verbesserung bringt und dann wieder ganz von vorne anfangen (Arnes und mein Optimierer), und gewisse Hoffnungen, gemischt ganzahlig-lineare Verfahren benutzen zu können. Zu letzteren bitte das Mailarchiv (ca. Januar) befragen. Ich meine ich hätte in irgendeiner e-mail in den letzten Wochen etwas von einer Kostenfunktion gelesen. Wenn du den entsprechenden Thread („Kriterien für ein optimiertes Layout“ ) liest bist du ziemlich auf der Höhe der aktuellen Diskussion. Diesbezüglich würde mich auch interessieren, ob ihr n-Gramme nutzt und wenn ja wieviel stellig ist das n-Gramm (Bigramm, Trigramm, ...)? Mein Optimierer geht bis zu Bigrammen, Arnes bis zu Trigrammen (soweit ich weiß, er kann mich ja korrigieren). Wobei die Kriterien für n=1 unklar sind und mit steigendem n unklarer werden. (vielleicht steige ich nach Beendigung des Studiums noch mit ein). Danach? Uns interessiert schon jetzt, welchen systematischen Einfluss die Wahl eines bestimmten Korpus hat. Zum Beispiel ist Ulf aufgefallen, dass im Leipziger Korpus Punkte häufiger als Kommas sind. In einem „literarischen“ Korpus ist es anders rum. Was weiß der Linguist zum Zusammenhang zwischen Textgattung und 1-, 2- und 3-Grammhäufigkeiten? Andreas
Re: [Neo] Kriterien für ein optimiertes Layout
Ist es irgendwie möglich, Schreibfehler eindeutig auf eine Tastenbelegung zurückzuführen? Statistisch vielleicht schon. Aber die Interpretation ist diffiziler als ich befürchtet habe: Pascals Beispiel mit „nihct“ hätte ich als Hinweis darauf gedeutet, dass Handwechsel schlecht sind, denn der Dreher taucht in einem Bigramm mit Handwechsel auf. Pascal interpretiert dasselbe Beispiel so, dass er gerne die Hand wechselt. Da haben wir eine ganz einfache Feststellung, und trotzdem würden wir vermutlich genau gegensätzliche Schlüsse zur Beurteilung von Handwechseln daraus ziehen, zumindest wenn wir auf die Urteile „gut“ und „schlecht“ beschränkt wären. Vielleicht ist es so, dass Handwechsel zeitlich schwerer zu koordinieren sind als Handwiederholungen, aber das Potenzial bieten, dank höherer Parallelität schneller zu tippen. Andreas
Re: [Neo] Woher den Platz für Modifikatortasten nehmen ?
1. Wenn man sie, wie von Pascal gewünscht, nach innen legt, muss das nicht heißen, dass man dadurch die Tasten, die mit gespreiztem Zeigefinger erreicht werden, verlieren muss. Mann könnte 3 statt der auf Standardtastaturen üblichen 2 Tastaturspalten zwischen die Hauptfingerspalten legen (wobei ich daran zweifele, dass das ergonomisch sinnvoll ist). Oder auch nur eine, dann muss man halt nach neuen Plätzen für Tasten suchen, die mit gespreiztem kleinen Finger erreicht werden (ß und y). 2. Wie bereits einmal vorgeschlagen, könnte man die Mods auf die Daumenreihe legen. Mehr Daumentasten würden sehr helfen. Aber wenn ich nicht völlig missverstehe sprichst du zumindest bei Punkt 2 von spezieller Tastaturhardware. Mir geht es in erster Linie um handelsübliche PC-Tastaturen. Die Dinger, die die IT-Abteilung für mich aussucht. Die Dinger, bei denen die Controltasten ganz unten ganz außen sitzen. Wobei ich anmerken möchte, dass ich jetzt bei KDE-Programmen beobachtet habe, dass Ä für Alt-Ä (Änderungen verwerfen) benutzt wurde. Interessant. Weißt du, unter welchen Bedingung dieses Tastaturkürzel aktiv wird? Hängt es zum Beispiel an der Umgebungsvariable LANG? Andreas
Re: [Neo] Woher den Platz für Modifikatortasten nehmen ?
Ihn nicht einfach wieder loslassen zu können, ja nicht einmal, ein beliebiges Zeichen danach tippen zu können, Man kann den doppelt benutzten Modifikator einfach wieder loslassen (Finger anheben), nur erzeugt das halt ein Zeichen, genau wie wenn man eine normale Taste drückt. Und danach kann man ein beliebiges Zeichen tippen, ganz wie immer; sobald der doppelt benutzte Modifikator losgelassen wird erzeugt er sein Zeichen, und das war's. Solange der doppelt benutzte Modifikator noch gedrückt ist kann man durch Drücken eines normalen Modifikators das Erzeugen eines Zeichens beim Loslassen des doppelt benutzte unterbinden. würde Neo technisch optimieren, Danke für die Blumen. aber Menschen sind keine Maschinen – – insbesondere sind sie lernfähig. Die Neigung, grundlos auf Modifikatoren zu drücken, ist hoffentlich nicht genetisch festgeschrieben. Woher kommt überhaupt die Befürchtung, die Tastatur hätte nicht genügend Tasten? Tasten gibt es genug, nur gut erreichbare nicht. Für mich als Emacs-User ist zum Beispiel die normale Position der Control-Tasten indiskutabel. Wenn ich bessere Positionen für Contol will muss ich schlechtere Positionen für andere Modifikatoren oder Zeichen in Kauf nehmen. Oder über das Permutieren von Belegungen hinausgehen. Oder Löten lernen. Andreas
Re: [Neo] Neo3 für Pascal?
Könnte man nicht theoretisch einen Treiber auf niedrigerem Niveau (in C) schreiben, der ganz hardwarenah die verschiedenen Signale der Tastatur nach Belieben umtauscht? Bestimmt. Etwas auf einem niedrigen Niveau zu machen gibt einem zwar viel Macht in die Hand, hat aber auch Nachteile: geringene Portabilität (was auf Linux geht hilft mir auf NetBSD wahrscheinlich nicht), schwierigere Konfiguration, schwerwiegendere Folgen von Bugs, mehr Rechte zur Installation. Gibt es etwas Ähnliches in Linux (unter X meine ich)? So Zahlencodes, meine ich? Kann man sie manipulieren oder im Sinne einer Umtauschtabelle verändern? Die keycodes in xmodmap sind solche Zahlencodes. Eine Zahl bezeichnet sowohl eine Taste als auch eine Zeile in der Belegungstabelle. Normalerweise genügt es, die Zahl zu lassen wie sie ist, und nur die Belegungstabelle zu ändern; das normale xmodmap-Procedere. Mit XKB kann man auch den Zahlencode selbst manipulieren. Zum einen gibt es zwei so genannte Overlays. Damit man kann jeder Taste (also jedem Zahlencode) zwei andere Tasten zuordnen. Ist das jeweilige Overlay aktiv werden die Zahlencodes entsprechend ausgetauscht. Zum anderen gibt es so genannte Redirect-Actions. Eine Redirect-Action ist im Grunde eine Tastenbelegung und kann nicht nur pro Taste, sondern auch pro Ebene spezifiziert werden. Statt einfach ein Symbol zu erzeugen wird aber zuerst der Zahlcode ausgetauscht (und allenfalls die Modifikatoren verändert). Symbole werden dann mit dem neuen Zahlencode aus der Belegungstabelle ausgelesen. Overlays sind zum Beispiel geeignet, einen Zahlenblock im Haupttastenfeld einzublenden (mit Vor- und Nachteilen gegenüber der Neo-Lösung mit Ebenen). Mit Redirect-Actions könnte man zum Beispiel Control-C irgendwo auf Ebene 4 legen. Andreas
Re: [Neo] Neo3 für Pascal?
Was wären denn die Nachteile? Könnten wir dann einen E4-Zahlenblock damit machen der endlich auch mit qt/kde vernünftig funktioniert? Ich denke schon, jedenfalls habe ich tatsächlich an solche Probleme gedacht. Zwar kann man auch wie im monolithischen Treiber mit Ebenen und Redirect-Actions arbeiten, aber das ist komplizierter als ein Overlay. Dafür bekommt man den Ebene-4-Lock richtig hin. Andreas
Re: [Neo] Neo3 für Pascal?
Zu (2) und (3): Es ist unerlässlich, dass wir mehr Freiwillige zum Probieren rekruttieren. Ich fürchte du hast Recht. Nur, übertrieben gesagt, eine Tastatur probieren bedeutet für mich, dass ich auf der Arbeit eine Tastaturbelegung lerne statt zu tun für was ich bezahlt werde. Da muss dann schon einige Aussicht bestehen, dass ich bei der Belegung bleibe. Und im Moment spuken mir noch ein paar halbgare Ideen im Kopf herum die ich erst (technisch) erfolgreich umsetzen oder ad acta legen will. Sagt mal was dazu! Geht das überhaupt? Mit XKB geht das, Peter hat schon längerer Zeit darauf hingewiesen. Und ich hatte das Verfahren sogar schon mal in meinem «monolithischen Treiber» drin, hab's aber wieder rausgeworfen, mangels eigenem Bedarf. Falls Interesse besteht kann das wieder reintun; für Neo2 muss Control-V dann halt mit QWERTZ-Control-Y erzeugt werden. Andreas
Re: [Neo] Neo3 für Pascal?
Und was ist das? Die „de/en“ habe ich irgendwie nicht mitgekriegt. Ist
das eine neue Entwicklung?
Sie ist das, was mit meinem derzeitigen Bewertungschema und einem
gemischt deutsch-englischen Korpus aus dem Optimierer geplumpst ist,
nicht mehr.
Nur eben C, V und X auf der rechten Hand.
Ja, aber drei Umlaute an deren QWERTZ-Position. Ich kenne kein Programm
dessen Bedienung Control-Umlaut verlangt, deshalb kann man in Verbindung
mit Control auf den Umlautpositionen problemlos Ctrl-{C,V,X} erzeugen.
Wie das mit XKB geht wurde von Peter schon erklärt (und auch wie man
Ctrl-Funktionen auf Ebene 4 schafft). Und die Linkshänder könnten
Ctrl-{C,V,X} endlich mit der rechten Hand bedienen. Gerade in dieser
Hinsicht ist die Tastatur prima, aber das ist purer Zufall;
Ctrl-{C,V,X,Z} meinem Optimierer derzeit (und mir sowieso) egal.
Vielleicht ist das Thema „Ziele von Neo 3“ nicht zu Ende diskutiert
worden? Vielleicht sollten wir „de/en“ benutzen?
Für mich ist Englisch wichtig, ich muss viel mehr Englisch als Deutsch
schreiben. Ob das für Neo3 ein Thema sein soll weiß ich nicht; es ist
auch nicht so wichtig, denn einen anderen Korpus zur Optimierung
benutzen ist eine einfache Sache, und in einem existierenden Treiber
Buchstaben zu vertauschen auch.
Aus meiner Sicht ist das Hauptproblem, gute Kriterien zur Beurteilung zu
finden. Ob man einer Kollision 200 Strafpunkte berechnet wie du, oder
nur 10±1 wie ich ist noch pure Willkür. Muss es immer Willkür bleiben
oder gibt es auch harte Argumente? Kraft- und Energieaufwand,
erreichbare Geschwindigkeit, Einschränkungen in der Fingerbeweglichkeit,
Verletzungsgefahr?
Andreas
Re: [Neo] Neo3 für Pascal?
2. Die Buchstabenlage ist sehr gut. Ich weiß, dass wir auf der Liste andere Analytiker haben. Es wäre interessant, weitere Meinungen zu hören. Keine Meinung, nur das, was mit meinen momentanen Kriterien und dem Leipziger Korpus rauskommt: QWERTZ 496.084 Gesamtaufwand 355.848 Lageaufwand links rechts 9.498 Kollisionen10.919 Shift-Kollisionen ob 31.0 16.9 qwert zuiopü51.323 Handwechsel52.098 Shift-Handwechsel mi 21.3 10.4 asdfg hjklöä18.763 Einwärts 32.641 Shift-Einwärtsun 8.2 18.8 yxcvb nm,.ß 18.142 Auswärts4.343 Shift-Auswärts sum 60.5 46.1 Finger 8.3 7.6 23.3 21.3 | 21.7 10.1 7.4 6.9 Shift 2.4 4.2 Neo2 310.851 Gesamtaufwand 200.426 Lageaufwand links rechts 6.494 Kollisionen 6.291 Shift-Kollisionen ob 8.7 10.6 xvlcw khgfqß64.507 Handwechsel32.439 Shift-Handwechsel mi 35.6 34.3 uiaeo snrtdy10.131 Einwärts 57.514 Shift-Einwärtsun 7.7 9.6 üöäpz bm,.j 16.594 Auswärts3.756 Shift-Auswärts sum 52.1 54.5 Finger 8.4 8.9 10.0 24.9 | 26.2 11.4 9.0 7.9 Shift 4.0 2.6 Eidur 256.672 Gesamtaufwand 200.131 Lageaufwand links rechts 0.808 Kollisionen18.900 Shift-Kollisionen ob 9.8 13.0 äuocj khlmvx70.849 Handwechsel21.786 Shift-Handwechsel mi 36.6 31.2 aietp gdnsrß14.092 Einwärts 56.533 Shift-Einwärtsun 7.5 8.6 .,üöq zbwfy 11.976 Auswärts2.781 Shift-Auswärts sum 53.9 52.7 Finger 11.9 12.3 19.2 10.5 | 16.5 14.8 10.5 10.9 Shift 4.5 2.1 Ganzneue 255.041 Gesamtaufwand 195.926 Lageaufwand links rechts 0.881 Kollisionen16.791 Shift-Kollisionen ob 10.5 13.7 äuocv khmlfq67.920 Handwechsel30.060 Shift-Handwechsel mi 37.6 31.2 aietb gdnrsß14.585 Einwärts 51.025 Shift-Einwärtsun 7.3 6.3 .,üöx pzwyj 14.340 Auswärts2.123 Shift-Auswärts sum 55.4 51.2 Finger 11.7 12.3 19.2 12.2 | 15.5 13.8 11.2 10.7 Shift 4.3 2.3 Deine bisherige 255.611 Gesamtaufwand 197.071 Lageaufwand links rechts 0.811 Kollisionen19.509 Shift-Kollisionen ob 10.6 12.3 äuocp khlmjx69.079 Handwechsel25.271 Shift-Handwechsel mi 37.6 31.2 aietb gdnsrß14.690 Einwärts 52.274 Shift-Einwärtsun 7.2 7.8 .,üöq vzwfy 13.145 Auswärts2.946 Shift-Auswärts sum 55.3 51.3 Finger 11.6 12.3 19.2 12.2 | 15.4 14.8 10.5 10.5 Shift 4.2 2.4 de/en 242.395 Gesamtaufwand 198.209 Lageaufwand links rechts 1.147 Kollisionen 3.361 Shift-Kollisionen ob 7.0 11.5 zuy,. jgclfß70.512 Handwechsel30.606 Shift-Handwechsel mi 36.2 35.1 hieao dtnrsv16.615 Einwärts 62.242 Shift-Einwärtsun 7.6 9.2 köüäq bpmwx 9.451 Auswärts3.791 Shift-Auswärts sum 50.8 55.8 Finger 11.4 11.6 16.6 11.1 | 17.2 15.1 12.5 11.1 Shift 4.6 2.0 Mit einem gemischten Korpus (die Essays aus c't 22/1999 bis 12/2006 und 4000 Zeilen aus dem Leipziger Englischkorpus, eine etwa 1:1-Mischung): QWERTZ 468.876 Gesamtaufwand 340.428 Lageaufwand links rechts 8.588 Kollisionen 9.798 Shift-Kollisionen ob 30.0 18.3 qwert zuiopü51.870 Handwechsel49.441 Shift-Handwechsel mi 21.6 9.9 asdfg hjklöä18.867 Einwärts 37.741 Shift-Einwärtsun 8.4 16.5 yxcvb nm,.ß 18.282 Auswärts3.019 Shift-Auswärts sum 59.9 44.7 Finger 9.2 8.0 21.7 21.0 | 19.7 10.1 9.7 5.3 Shift 1.7 2.9 Neo2 301.757 Gesamtaufwand 187.023 Lageaufwand links rechts 7.610 Kollisionen 5.501 Shift-Kollisionen ob 9.6 9.6 xvlcw khgfqß62.370 Handwechsel36.781 Shift-Handwechsel mi 36.7 34.5 uiaeo snrtdy11.666 Einwärts 55.490 Shift-Einwärtsun 5.7 8.6 üöäpz bm,.j 15.961 Auswärts2.228 Shift-Auswärts sum 52.0 52.7 Finger 6.3 8.9 10.9 25.9 | 24.6 10.4 10.1 7.5 Shift 2.7 2.0 Eidur 244.100 Gesamtaufwand 189.923 Lageaufwand links rechts 1.179 Kollisionen16.698 Shift-Kollisionen ob 11.6 12.9 äuocj khlmvx69.149 Handwechsel24.967 Shift-Handwechsel mi 37.5 28.8 aietp gdnsrß13.927 Einwärts 55.617 Shift-Einwärtsun 5.5 8.3 .,üöq zbwfy 13.351 Auswärts2.718 Shift-Auswärts sum 54.6 50.1 Finger 10.8 12.2 19.3 12.3 | 14.5 14.2 10.8 10.7 Shift 2.8 1.8 Ganzneue 245.854 Gesamtaufwand 188.533 Lageaufwand links rechts 1.274 Kollisionen14.715 Shift-Kollisionen ob 12.3 13.7 äuocv khmlfq66.778 Handwechsel29.574 Shift-Handwechsel mi 37.6 28.8 aietb gdnrsß14.499 Einwärts 53.006 Shift-Einwärtsun 5.5 6.7 .,üöx pzwyj 15.056 Auswärts2.705 Shift-Auswärts sum 55.5 49.2 Finger 10.7 12.2 19.3 13.3 | 14.4 12.9 11.6 10.4 Shift 2.8 1.9 Deine bisherige 245.135
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
z(ij) ≥ a(ij)c(tu)·(z(it)+z(ju)-1) ∀ i∈I, j∈I, t∈T, u∈T Diese Nebenbedingung ist tatsächlich ein wenig groß, auch wenn ein recht hoher Teil schon rausfällt, da, wenn t und u sich auf beide Hände verteilen, c(tu) ja 0 sein müsste. Das ist natürlich viel besser als mein Vorschlag. Mit Ulfs Kriterium kommt man grob gepeilt auf eine viertel Million Nebenbedingungen. Ist das viel? Wenn man in der Testphase nur Fingerkollisionen berücksichtigt bringt man die Anzahl der Bedingungen noch weiter runter. Andreas
Re: [Neo] Wie groß muss ein Korpus sein?
interessanter fände ich es etwa, den 1M-Leipzig-Korpus mit einem 1M-Wikipedia-Korpus zu vergleichen. Dann bekommt man allenfalls eine Aussage über den systematischen Fehler und erfährt nichts über den statistischen Fehler. Der systematische Fehler hat nichts mit der Korpusgröße zu tun, sondern mit der geeigneten Auswahl der Quellen. Das ist wichtiges, aber ein anderes Thema. Ansonsten dürfte unbestritten sein, dass bei selteneren Zeichen wie »αℤ ein größerer Testkorpus genauer bzw. aufschlussreicher wäre … da ist eher die Frage, ob dies für die automatische Optimierung überhaupt relevant ist oder vernachlässigt werden könnte. Wenn ein Zeichen wirklich selten ist spielt es automatisch in der Gesamtwertung kaum keine Rolle, zumindest wenn man ein in den Häufigkeiten lineares Beurteilungsschema verwendet. Mit Sonderzeichen gibt noch ein ersteres Problem als die Statistik: Die Häufigkeiten sind stark von der Quelle abhängig. Zum Beispiel gibt es im Leipziger Korpus recht viele geraden Anführungszeichen (), die anstelle typographisch korrekter Anführungszeichen benutzt werden. Würden wir das Neo-Mailinglisten-Archiv als Quelle benutzen wäre das anders. Bei Exoten wie ℤ muss man sogar sicherstellen, dass statt des eigentlichen Zeichens nicht ein Bildchen verwendet wird; bei Mathematik auf dem Web ist das immer noch üblich. Vor dem Problem der Korpusgröße steht bei Sonderzeichen, insbesondere seltenen, also das Problem der Quellenauswahl und allfälliger manueller Nachbesserung. Auch ein 3G Leipziger Korpus würde hier nichts helfen, sondern im Gegenteil nur die manuelle Nachbesserung erschweren. Andreas
Re: [Neo] Wie groß muss ein Korpus sein?
Je nachdem, welche Informationen aus dem Textkörper geholt werden sollen, kann ein größerer Textkörper erforderlich sein. Das ist richtig. Für ein Gesamturteil reicht ein recht kleiner Korpus, weil es sich aus vielen Einzelhäufigkeiten zusammensetzt, oder anders ausgedrückt, einen Großteil der Information im Korpus tatsächlich auch verwendet. Interessant könnte sein, einen Textkörper in einer Matrix abzubilden, die die Wahrscheinlichkeiten enthält, mit der ein Zeichen auf ein anderes folgt (bzw. ihm voraus geht). Wenn man die Bigrammhäufigkeiten mit der Häufigkeit des betreffenden Zeichens normiert hat man genau das. Zum Erzeugen solch einer Matrix (z. B. anhand einer Trigrammliste nach dem mittleren Zeichen sortiert) erscheint mir tatsächlich ein recht großer Textkörper erforderlich, wenn der Fehler im relevanten Bereich nicht zu hoch werden soll. Wenn einem wirklich an jedem einzelnen Eintrag der Matrix liegt braucht man tatsächlich einen großen Korpus. Für die Tastaturoptimierung liegt einem aber nicht an jedem einzelnen Eintrag. Kann man anhand der Fehlerbetrachtung für Bigramme auch auf eine für Trigramme schließen? Wenn man den statistischen Fehler für die Häufigkeit eines bestimmten Trigramms haben will kann man diese nicht einfach aus dem statistischen Fehler der beiden enthaltenen Bigramme gewinnen. Andererseits glaube ich nicht, dass sich die Anforderungen an den Korpus wesentlich ändern, wenn man Trigramme in die Gesamtbewertung mit einbezieht, vorrausgesetzt, man tut das vernünftig. Andreas
Re: [Neo] Automatische Optimierung
Ich würde persönlich erstmal Shift ignorieren (ist das der Bug?) Klar, nur etwa 5% der Zeichen sind Großbuchstaben, und ihre Häufigkeit ist durch den Text, nicht durch die Belegung vorgegeben. Das spricht dafür, sie zu ignorieren. Andererseits, falls man sich wegen einem Prozent mehr oder weniger Fingerkollisionen Gedanken macht kommt man um die Berücksichtigung von Shift kaum herum. Zum Beispiel: Eidur 251.831 Gesamtaufwand 190.763 Lageaufwand links rechts 0.808 Kollisionen18.900 Shift-Kollisionen ob 9.8 13.0 äuocj khlmvx70.849 Handwechsel21.786 Shift-Handwechsel mi 36.6 31.2 aietp gdnsrß14.092 Einwärts 56.533 Shift-Einwärtsun 7.5 8.6 .,üöq zbwfy 11.976 Auswärts2.781 Shift-Auswärts sum 53.9 52.7 Finger 11.9 12.3 19.2 10.5 | 16.5 14.8 10.5 10.9 Shift 4.5 2.1 Hier verdoppelt sich die Anzahl Kollisionen, sobald man die Kollisionen mitzählt, bei denen der gleiche kleine Finger erst Shift drückt und direkt danach eine andere Taste anschlagen muss oder umgekehrt (oben Shift-Kollision genannt, die Zahl ist auf die Zahl der Bigramme mit Großbuchstaben bezogen). Die Lagepunkte sind nach meiner Meinung in erster Linie ein Werkzeug um das Programm in bestimmte Bahnen zu zwingen und können so auch nicht Gegenstand einer demokratischen Umfrage werden (!). Ich sehe das technokratischer. Wenn die Lagepunkte nicht interessieren lässt man sie weg; wenn sie interessieren sollten sie vernünftig sein und angemessen gewichtet werden, sonst vermasseln sie nur die automatische Optimierung. 10 238.143 Gesamtaufwand 189.086 Lageaufwand links rechts 0.797 Kollisionen 6.650 Shift-Kollisionen ob 8.1 13.3 cüo., bgmlfß70.905 Handwechsel23.395 Shift-Handwechsel mi 39.2 32.2 teaiu hdnrsx14.225 Einwärts 66.138 Shift-Einwärtsun 6.0 7.8 jqäöy kpwvz 11.798 Auswärts3.817 Shift-Auswärts sum 53.3 53.3 Finger 14.0 16.6 9.0 13.7 | 16.3 13.8 12.1 11.2 Shift 4.8 1.8 So eine Ähnliche habe ich mehrmals gehabt. Ich bekomme aber: === cüo., bgmlfß teaiu hdnrsx jqäöy kpwvz Lagepunkte145 Fingerwiederholung 0.770 % Handwechsel... 74.543 % Einwärtsbewegung.. 14.958 % Auswärtsbewegung.. 9.730 % Fingerverteilung: 9.17 16.55 9.01 13.74 | 16.35 13.76 12.06 9.36 Deine Prozente Wiederholung, Wechsel, Einwärts, Auswärts summieren sich nicht zu 100%. Das stört irgendwie. Bei Kollisionen zähle ich Mehrfachanschläge (also zum Beispiel «ll») nicht mit. Ich gebe sie auch nicht mit der Tastatur, sondern mit der Korpusstatistik aus, denn sie sind eine Eigenschaft des Korpus, nicht der Belegung. Die Unterschiede kommen vermutlich von den Bigrammhäufigkeiten. bigramme-de.txt von deiner Homepage sieht deutlich anders aus als Karls 2gramme.txt. Du verwendest die 1M Datei, Karl die 3M Datei. Mit sentences.txt aus der 100k-Datei bekomme ich eine ähnliche Verteilung wie Karl. Wenn man eine Eigenschaft optimiert, leidet vielleicht eine andere. Wenn es anders wäre würde ich dem Optimierer nicht trauen. Andreas
[Neo] Wie groß muss ein Korpus sein?
Damit die Beurteilung einer Tastatur nicht zu sehr durch zufällige Variation der Zeichen- und Bigrammhäufigkeiten beeinflusst wird, muss der Korpus groß genug sein. Die Frage ist, wie groß. Die Beurteilung einer Tastatur wird durch eine Zahl ausgedrückt. Man kann sich überlegen, dass für einen sehr große Korpora der relative statistische Fehler dieser Zahl reziprok zur Wurzel der Größe eines Korpus ist. Dieses qualitative Verhalten sollte nicht vom Bewertungsschema und der gegeben Tastatur abhängen; der Vorfaktor kann das aber durchaus. Um den Vorfaktor zu bekommen habe ich zwei Tastaturen, eine (gemäß meinen aktuellen Kriterien) besonders gute und eine besonders schlechte, mit verschiedenen Korpora bewertet und aus den Einzelergebnissen den relativen Fehler (Standardabweichung durch Mittelwert) bestimmt. Die Korpora habe ich aus dem Leipziger 1M-Korpus gewonnen, indem ich diesen einmal in 1000 Files zu je 1000 Zeilen und einmal in 100 Files zu je 1 Zeilen aufgespaltet habe. Resultat: Mittel rel. Fehler Files Zeilen Tastatur 236.353 0.00140541 1001 optimiert 236.357 0.00394096 10001000 optimiert 984.445 0.000574423 1001 pessimiert 984.446 0.0018825 10001000 pessimiert So ein 1-Zeilen-File hat etwa 1.1 MByte, und der relative statistische Fehler der Bewertung ist im Promillebereich. Wenn wir uns als Ziel setzen, den statistischen Fehler unter einem Promille zu halten (die Willkür im Bewertungschema wird viel größer sein als das), ist ein Korpus von 3 MByte also groß genug. Andreas
Re: [Neo] Automatische Optimierung
Ich habe in Python deinen damals beschriebenen Algorithmus geschrieben. Prima. Mit Python haben sicher mehr Leute die Möglichkeit, mit dem Algorithmus und mit Bewertungschemas zu spielen. 1. Mache eine zufällige Tastatur 2. Tausche zwei Zeichen. Gibt das bessere Punkte, dann mache mit „2“ weiter. Gibt es nicht bessere Punkte, dann tausche zwei anderen ( bis 32 * 32 = 1024 minus 32 die gleich sind - 992 Möglichkeiten erschöpft sind). 3. Ist keine Besserung mehr möglich, dann höre auf. Das ist doch so richtig oder nicht? Bei Punkt 2 bin ich nicht sicher. In meiner ersten Variante probiere ich erst alle 992 möglichen Vertauschungen. Erst dann nehme ich die Beste davon. In meiner zweiten Variante fange ich bei einer zufälligen Vertauschung an und suche von da ab die erste, die eine Verbesserung bringt. Wichtig ist «zufällig»; fängt man immer an derselben Stelle an kommt das vermutlich nicht gut (hab's aber nicht probiert). Nur 1 von 25 Tastaturen gefällt mir. Sie sind nicht so schöne wie deine. Ich schaue nur Resultate an, die eine gute Wertung haben, ansonsten probiere ich gleich nochmal. Vielleicht ist das ja der einzige Unterschied; es passt auch zu den Laufzeiten, die du nennst. Wie bewertest du ganz genau? Ich habe ein paarmal dran gedreht, für «Ohne Shift» war es so: - Einzeltasten wie in deinem Auswerteprogramm mit Ausnahme von QWERTZ-n; hier 5 statt 7 Punkte. - Mehrfachanschlag: Differenz aus Einzeltastenwert und dem Einzeltastenwert der Grundposition des betreffenden Fingers (also etwas negatives für Tasten außerhalb der Grundposition). - Andere Fingerwiederholung (also Kollisionen): 9 plus zweimal Absolutwert der Differenz der Spaltennummern der beiden Tasten. - Andere Handwiederholung: Für Einwärtsrolle 1 plus das Verhältnis aus dem Absolutwert der Zeilennummerdifferenz und dem Absolutwert der Spaltennummerdifferenz; für Auswärtsrolle noch einen Punkt mehr. Für «Mit Shift» kommen noch Strafpunkte dazu, das Schema für diese ist ähnlich. Es bedarf demnach oft mehr als eine Mutation bevor eine Besserung eintritt. Das geht bei deinem Algorithmus nicht. Da muss jede Mutation eine Besserung bringen. Auch mal was zum überlegen??? Ja, und deswegen hat es mich überrascht, dass der Algorithmus überhaupt etwas Brauchbares liefert. Ich hatte erwartet, dass man praktisch immer bei irgendetwas mittelmäßigem stecken bleibt. In Variation meines Verfahrens könne man auch Verschlechterungen akzeptieren, aber mit geringerer Wahrscheinlichkeit als Verbesserungen. Ich habe schon ein wenig in der Richtung probiert, aber ohne Erfolg. Vielleicht braucht man tatsächlich noch «Replikation» und «Vererbung», um erreichte Qualitäten nicht an den Zufall zu verlieren. Wenn ich mit deinem Algorithmus 50 Tastaturen mache und lasse sie durch meinen laufen kommen scheinbar sehr gute heraus. Bei Interesse werde ich davon welche hier posten. Ja, ich habe Interesse. Ich möchte eine deiner sehr guten Tastaturen mit meinen Kriterien beurteilen und sehen, ob sie danach tatsächlich besser ist als Beste mit meinem Algorithmus gefundene. Wenn ja ist die Kombination der Algorithmen tatsächlich ein weiterer Fortschritt. Wenn nein kommen die Unterschiede wohl von unterschiedlichen Kriterien oder vom unterschiedlichen Korpus. Andreas
Re: [Neo] Automatische Optimierung
In meiner ersten Variante probiere ich erst alle 992 möglichen Vertauschungen. Will natürlich sagen, 992/2 mögliche Vertauschungen. x mit y zu tauschen ist ja dasselbe wie y mit x zu tauschen. Andreas
Re: [Neo] Automatische Optimierung
Wenn ich mich nicht irre sind aber bei k Belegungen auf n Tasten „nur“ n!/(n-k)! Kombinationen zu untersuchen, was die Sache etwas vereinfacht. Ja, stimmt. Ich denke, die entscheidende Frage ist die Dauer einer Evaluation. Und die hängt von der Qualität der Abschätzung ab. Ich habe hier einen etwas älteren Schmierzettel auf dem was von n³ Operationen steht, aber ich verstehe ihn selbst nicht mehr ganz. n³, das wäre im Millisekundenbereich. Auch ist die Frage, wieviele Kombinationen denn so rausfliegen werden. In der Tat, und mir ist nicht wohl dabei. Andreas
Re: [Neo] Dilettieren mit automatischer Optimierung
Ich habe den Optimierer so erweitert, dass er Shift berücksichtigen kann. Nach der Metrik die ich dabei verwende macht es durchaus einen Unterschied ob man das tut oder nicht, wenn auch nicht dramatisch (vergleiche die ohne Berücksichtigung von Shift optimierte Tastatur «Ohne Shift» und die mit Berücksichtigung von Shift optimierte Tastatur «Mit Shift» unten). Für den Vergleich habe ich den Leipziger Textkorpus verwendet (genauer gesagt die Tabellen «1gramme.txt» und «2gramme.txt» die Karl daraus erzeugt hat). Im Vergleich unten ist der Gesamtaufwand in jedem Fall mit Berücksichtigung von Shift berechnet. Die Details sind nicht sehr spannend; falls sich noch doch jemand dafür interessiert, wie die Beurteilung gemacht wird, siehe den Quellcode (URL wie gehabt). Außerdem habe ich den Algorithmus umgestellt: Statt des besten Tausches wird in jeder Iteration (ausgehend von einer zufälligen Stelle) der erste Tausch gemacht der eine Verbesserung bringt. Dadurch läuft der Optimierer im Mittel etwas schneller. Die Tastaturen «Mit Shift» und «Ohne Shift» wurden nach jeweils ein paar Sekunden Laufzeit gefunden. Andreas Großbuchstaben:6.587 % Mehrfachanschläge: 2.275 % Mit Shift 232.102 Gesamtaufwand 185.108 Lageaufwand 1.137 Kollisionen 2.972 Shift-Kollisionen kzo., cgmlfq70.480 Handwechsel30.643 Shift-Handwechsel haeiu dtnrsß17.774 Einwärts 62.551 Shift-Einwärts xüäöy pbwvj 8.335 Auswärts3.834 Shift-Auswärts Ohne Shift 240.870 Gesamtaufwand 184.706 Lageaufwand 0.780 Kollisionen18.054 Shift-Kollisionen äco., bgmlvß71.200 Handwechsel19.564 Shift-Handwechsel ateiu hdsnrx15.468 Einwärts 57.669 Shift-Einwärts qpöüy kfzwj 10.277 Auswärts4.713 Shift-Auswärts Bro251.192 Gesamtaufwand 192.434 Lageaufwand 1.983 Kollisionen 8.281 Shift-Kollisionen xpc,y kghlfß71.816 Handwechsel20.658 Shift-Handwechsel uieao dtnrsj13.806 Einwärts 67.006 Shift-Einwärts üqä.ö vmbzw 10.120 Auswärts4.056 Shift-Auswärts Moesi HP 261.699 Gesamtaufwand 201.847 Lageaufwand 1.472 Kollisionen13.236 Shift-Kollisionen yoa,j kgclfx70.946 Handwechsel27.210 Shift-Handwechsel iuehp dtnrsß13.803 Einwärts 55.483 Shift-Einwärts üöä.q vmbzw 11.505 Auswärts4.071 Shift-Auswärts Moesi Var. 266.465 Gesamtaufwand 206.318 Lageaufwand 1.605 Kollisionen13.691 Shift-Kollisionen yoa,j kghlfx71.596 Handwechsel22.573 Shift-Handwechsel iuecp dtnrsß14.252 Einwärts 59.520 Shift-Einwärts üöä.q vmbzw 10.272 Auswärts4.217 Shift-Auswärts Neo2 294.627 Gesamtaufwand 191.699 Lageaufwand 6.494 Kollisionen 6.291 Shift-Kollisionen xvlcw khgfqß64.507 Handwechsel32.439 Shift-Handwechsel uiaeo snrtdy10.131 Einwärts 57.514 Shift-Einwärts üöäpz bm,.j 16.594 Auswärts3.756 Shift-Auswärts
Re: [Neo] Handwechsel maximieren
Umkehrt: Viele Strafpunkte für Handwechsel, wenige für andere Kriterien (der Optimierer versucht die Strafpunkte zu minimieren). Das kann ich nicht glauben. Du hast recht. Richtig wäre «Handwiederholung» statt «Handwechsel». Andreas
Re: [Neo] Handwechsel maximieren
Verstehe ich das mit den Strafpunkten richtig: Handwechselstrafpunkte minimal bei allen anderen Kriterien maximale Strafpunkte veranlasst den Optimierer, die Zeichen so auszugeben, dass für den zugrundegelegten Textkörper die Handwechsel maximal werden. Umkehrt: Viele Strafpunkte für Handwechsel, wenige für andere Kriterien (der Optimierer versucht die Strafpunkte zu minimieren). Wie umfangreich war der zugrunde gelegte Textkörper? 11 MB, der kleinste der Leipziger Textkörper. Übrigens, vielen Dank für die fertigen Tabellen für den vollen Textkörper; ich werde einstweilen deine 1- und 2-Gramme verwenden. Bei meinem Ergebnis bin ich mir nicht sicher, weshalb die Untersuchung später genauer wiederholt werden soll. Deine Untersuchung braucht nicht wiederholt werden: Wenn wir die Gesamthäufgkeit eines Zeichen n nennen, und die Summen der Häufigkeiten mit der es in der ersten bzw. zweiten Position eines Bigramms auftaucht n₁ und n₂, dann ist, von der Skalierung abgesehen, die Größe in deiner Klassifikation n₂-n₁ = (n-n₁)-(n-n₂). Nun sind n-n₁ und n-n₂ offenbar die Häufigkeiten des Zeichens am Wortende und Wortanfang, das heisst, deine Klassfikation geht danach, ob ein Zeichen eher am Anfang oder am Ende von Wörtern steht. Ein gutes Kriterium für Sprachen deren Wörter typischeweise zwei Buchstaben haben, ein schlechtes für Sprachen deren Wörter typischeweise drei Buchstaben haben, ein irrelevantes für Deutsch. Kann mit dem Optimierer überprüft werden, wie hoch Handwechsel zu einem bestimmten Korpus sind, wenn vorher feststeht, welche Zeichen mit welcher Hand (egal auf welcher Taste) bedient werden sollen? Klar, aber ein Auswerteprogramm tut es auch. Andreas
Re: [Neo] Handwechsel maximieren
im Vorfeld kann anhand von Bigrammen ermittelt werden, welche Zeichen zu welcher Hand zugeordnet die Handwechsel maximieren. Wenn ich in meinem Optimierer die Stafpunke für Handwiederholung zum dominanten Kriterium mache schlägt er vor: öp.o, mlghbv uiaec dnrtsj xyüäq ßwkfz Andreas
Re: [Neo] [ticket] #141: Neue xkbmap-Version setzt xkbmap außer Gefecht
Bleibt die Möglichkeit, die Tasten gleich selbst mit den Mods zu belegen. Gibt’s da Erfahrungen? Wenn ich dich richtig verstehe ist die Frage, ob man die Zuordnung zwischen reellen und virtuellen Modifikatoren statt per MDSW (und HYPR) mit den Neo-Mod4-Tasten machen kann, mit virtualmodifiers in der key-Definition in xkb_symbols. Im Prinzip ja. Wir müssen zwei Zuordnungen machen: zwischen LevelFive und Mod3 sowie zwischen NumLock und Mod2. Da wir zwei Neo-Mod4-Tasten haben kann die eine Taste die eine, die andere Taste die andere Zuordnung übernehmen. Im Prinzip. Es ist schon eine Weile her, aber soweit ich mich erinnere hat das bei mir funktioniert, bei Stephan nicht. Probiert habe ich mit einem einzigen Layout, und damals auch noch mit expliziten actions in xkb_symbols statt dem Umweg über xkb_compartibility. Es gibt vielleicht noch eine Möglichkeit: Die Neo-spezifische Belegung für MDSW und HYPR in allen Layouts zu verwenden. Im Moment werden diese Tasten in anderen Layouts nicht sinnvoll benutzt (HYPR verbindet zwar den virtuellen Modifikator Hyper mit dem reellen Mod4, aber das könnte SUPR miterledigen). Andreas
Re: [Neo] Neo und Kyrillisch
Hast du es mal richtig getestet? Wie gefällt es dir? Ich habe nur die Tasten durchprobiert und verifiziert, dass die Erzeugung der Großbuchstaben per X-Modifier «Lock» für alle Buchstaben funktioniert. Aus Anwendersicht kann ich den Entwurf mangels Sprachkenntnissen nicht beurteilen. Aus Implementierungssicht ist es elegant, dass du alle Buchstaben auf Tasten untergebracht hast, die auch auf Ebene 1 Buchstaben haben. Andreas
Re: [Neo] Tote Tasten, Griechisch
Gundsätzlich ist es möglich, die Modifier getrennt zu loggen, so dass ein Shift-Lock und ein Mod3-Lock insgesamt die Ebene 5 ergäbe, ABER… Es steht dann kein normals Leerzeichen, kein Komma, kein Punkt, kein Gedankenstrich, keine Klammern, keine Anführungszeichen, … zur Verfügung. Das Schreiben eines Textes ist auf diese Weise also nicht sinnvoll. Mit XKB hat man noch mehr Möglichkeiten. Der Treiber benutzt 5 X-Modifier für nur 7 Levels; da ist noch viel Luft drin. Im meinem monolithischen Treiber wird z.B. ein Kyrillisch-Lock per X-Mod2-Lock und X-Lock-Lock (Neo-Mod4-Lock und Neo-CapsLock) realisiert. Nur Buchstabentasten sind betroffen, alle anderen Tasten funktionieren wie ohne Locks, Ebene 3, 4, und 5 funktionieren auf allen Tasten. Für den offiziellen XKB-Treiber ist dieser Weg allerdings problematisch, da man dazu ganz spezielle xkb_types braucht die von anderen Projekten kaum wiederzuverwerten sind. In dieser Hinsicht ist ein neo_griechisch wie es dir vorschwebt der bessere Weg, auch wenn man dazu mehr knappe Ressourcen (in diesem Falle XKB-groups) verbraucht. Andreas
Re: [Neo] Neo und Kyrillisch
ich habe einfach mal eine symbols/de-kyr und cyrillic.module ins SVN geladen, wenn es sich mal jemand anschauen will. Was ist mit T1? Du hast da ein Ь im Bildchen, aber in de-kyr nichts Spezielles. Ich habe deinen Vorschlag als siebente Ebene in den monolithischen Treiber aufgenommen (eine neue Ebene reicht, die Großbuchstaben kann man aus den Kleinbuchstaben generieren). Mit CapsLock+Mod4-Lock kann man die Kyrillisch-Ebene fest einstellen. Ich weiß nicht ob das Ganze praktisch nutzt, technisch ist es aber interessant… Wen es interessiert findet hier ein Skript, das einen monolithischen Treiber generiert bzw. einen fertigen Treiber (der für Linux mit evdev aber noch angepasst werden muss, siehe Kommentare): http://wettstae.home.solnet.ch/neo.sh.gz http://wettstae.home.solnet.ch/neo_ch_de_us.xkb.gz Andreas
Re: [Neo] Silbentastatur und Kurzschrift
Ein Mittelweg wäre, ein oder zwei halbwegs gute Positionen für spezielle tote Tasten zu opfern, und diese tote Tasten als Präfix für wichtige Wörter oder Silben zu verwenden. Das wäre dann im Prinzip schon ein zweites vollwertiges Compose … auch eine interessante Idee. Zumindest unter X würde man den normalen Compose/Tote-Tasten-Mechanismus verwenden. Speziell wäre an den neuen toten Tasten nur, dass sie sonst noch nicht verwendet werden, daher keine Konflikte mit Bestehendem auftreten, und damit kurze Tippsequenzen möglich werden. Wenn man auf (kurze) Silben statt (längere) Wörter abzielt ist das besonders wichtig. Andreas
Re: [Neo] Silbentastatur und Kurzschrift
Ich bin mir auch nicht sicher, ob man dieses Problem dadurch aus der Welt schaffen könnte, auf ♫ zu verzichten und einfach alle Buchstaben zu töten (analog zu meinem immer noch heißgeliebten ßß→ſs Fix). Ein Mittelweg wäre, ein oder zwei halbwegs gute Positionen für spezielle tote Tasten zu opfern, und diese tote Tasten als Präfix für wichtige Wörter oder Silben zu verwenden. Vielleicht könnte man auch sehr seltene Buchstaben auf diesem Weg erzeugen (und deren Platz für Wichtigeres verwenden, etwa für die ein oder zwei speziellen toten Tasten). Andreas
Re: [Neo] OSD Neo2
das ging ja fix mit der Änderung. Ich habe mir die neue Datei von
http://neo-layout.org/neo_de.xmodmap heruntergeladen, allerdings stimmen die
Modifier jetzt eher noch weniger als vorher... ;)
[Xmodmap]
Neo2X11
===
SHIFT shift
CAPS_LOCK shift_lock
MOD3(nicht gemeldet)
MOD4mod3 + mod5
MOD4_LOCK mod3_lock + mod5_lock (und das auch nur gelegentlich)
Die Buchstaben, die letztendlich beim Tippen herauskommen, stimmen übrigens
mit
den erwarteten überein.
Du siehst von Neo-MOD3 deshalb nichts, weil xmodmap zum Erreichen der
Ebenen 3 und 6 nicht zwischen «levels» sonder zwischen «groups»
umschaltet, und dabei sind keine Modifier beteiligt. Zur Illustration
ist hier die XKB-Sicht auf das, was xmodmap für i produziert:
key AC02 {
type[group1]= FOUR_LEVEL_ALPHABETIC,
symbols[Group1]= [ i, I,Left,
Left ],
symbols[Group2]= [ slash, Greek_iota ],
symbols[Group3]= [integral ]
};
Andreas
Re: [Neo] Belegung der toten Tasten
Was mir vielleicht ein bisschen zu viel des Guten ist, ist der E6-Lock, ansonsten finde ich den Tausch von E5/6 und die Einführung von E8 gut (was kommt dann auf die griechischen Buchstaben auf E5? Die wären dann ja doppelt. Fragen über Fragen …). Als Barbar bin ich mir nicht sicher: Braucht man noch andere griechische Großbuchstaben auer denen, zu denen es auf Ebene 5 Kleinbuchstaben gibt? Falls nicht könnte man die Großbuchstaben auch per CapsLock aus den Kleinbuchstaben erzeugen. Im Moment legt die Referenz nicht genau fest ob CapsLock auf griechische Buchstaben wirken soll, daher «dürfen» Implementierungen das. Der XKB-Treiber sieht griechische Buchstaben als mathematisches Symbole an und treibt einigen Aufwand um zu verhindern, dass sie bei aktivem CapsLock in Großbuchstaben umgewandelt werden. Das kann man aber ändern. Um die Großbuchstaben bequem erreichbar zu machen, brächte man noch ein Ebene 5-Lock und ein nichtlockendes CapsLock auf Ebene 5 von Shift. Dergleichen sollte man wohl Privatimplementierungen von Enthusiasten überlassen. Und Level8 wäre noch frei für Kyrillisch… Andreas
Re: [Neo] Abstraktionsgrad der Referenz (was: Re: KP_-Varianten: Referenz vs. xkbmap und xmodmap)
Bitte beschreibe genau unter welchen Umständen das passiert – vielleicht haben wir noch immer diese Keysyms noch nicht ganz richtig verstanden. Mit OpenOffice und schweizerdeutschen Spracheinstellungen, Details siehe unten. Nichts Neues. Ich würde nicht erwarten, dass man die keysyms verstehen kann; unter X macht halt traditionell jedes Programm was dem Programmierer gerade gepasst hat. Nur damit ich dein Problem endlich verstehe: Lade bitte mal die Neo-Xmodmap und sag mir, was bei dir die Taste neben der 0 auf dem Keypad Da ich hier ein NetBSD ohne OpenOffice habe, habe ich folgendes mit einer Ubuntu 9.04-LiveCD und der aktuellen xmodmap ausprobiert: • in der Bash (X-Konsole) • mit Shift in der Bash • mit Mod3 in der Basch Komma, Punkt, Komma (bash in xterm, unabhängig von LC_ALL) • in deinem OpenOffice (Schweiz) • mit Shift in deinem OpenOffice • mit Mod3 in deinem OpenOffice Punkt, Punkt, Komma (In OpenOffice 3.0, mit German(Switzerland) unter Tools Options Language Settings Languages eingestellt, Häkchen hinter «Decimal separator key» gesetzt). Ich verstehe, warum du dieses Argument anführst. Aber: KP_Sepataor löst den gehaltenen Klick! Nicht wirklich. Die Details hängen von der Anwendung ab. In Emacs wird mit KP_Separator die Hervorhebung des markierten Bereichs abgeschaltet; in xterm passiert das nicht, dafür wird das Wort unter dem Mauszeiger komplett mitselektiert. Beides ist nicht korrekt. Das Schlimmste (unter Ubuntu wie unter NetBSD) ist, dass abschließend das Setzen des gehaltenen Klick nicht mehr richtig funktioniert. (Probier zwei Sequenzen von KP_0, Maus bewegen, KP_Separator auszuführen; beim zweiten Mal funktioniert KP_0 nicht mehr). Andreas
Re: [Neo] KP_-Varianten: Referenz vs. xkbmap und xmodmap
Zu Beginn will ich einen erfreulichen Umstand anmerken der denen, die diese Diskussion in «epischer Breite» mitgemacht haben, bekannt sein sollte, mir aber neu war: Unser Sorgenkind OpenOffice hat unter ToolsOptionsLanguage Settings Languages ein Kästchen «Decimal separator key». Entfernt man dort das Häckchen, ergibt KP_Seperator ein Komma, KP_Decimal einen Punkt. Getestet mit OpenOffice 3.0 von der Ubuntu 9.04 LiveCD, mit deutschem Locale und monolithischem Treiber. Unser (einziges) Sorgenkind ist also gar keines. Und jetzt zu den strittigen Dingen. Wenn es nach mir ginge, würde ich dem period und komma auf dem echten, KP_Decimal und KP_Seperator auf dem Ebene 4-Ziffernblock verwenden. Das ist in jedem Fall ein schlechter Vorschlag. Erstens verliert man dadurch Funktionalität auf dem Keypad. Zweitens ergeben Separator und Decimal in OpenOffice (und vermutlich auch in anderen Programmen) das gleiche – heißt: es gibt auf der Ebene 4 in solchen Programmen keinen Punkt mehr. Ich bin mittlerweile der Ansicht, dass der Vorschlag tatsächlich schlecht ist, aber aus anderen Gründen als denen, die du nennst. Er hat nämlich dieselbe Schwäche wie die Referenz: Er diktiert eine Implementierung, statt sich darauf zu beschränken, das gewünschte Verhalten der Neo-Belegung zu spezifizieren. Systemspezifischer Kram wie X-Keysyms haben in einer allgemeinen Referenz nichts verloren. Und Hacks wie der KP_Separator/comma-Hack, die ein nicht existierendes Problem mit einer einzigen Anwendung auf einer bestimmten Plattform umgehen (aber nur wenn das Locale zufällig passt) schon garnicht. Im Moment ist das eine akademische Kritik an der Referenz. Praktisch relevant wäre sie gewesen, wenn OpenOffice tatsächlich ein «Sorgenkind» gewesen wäre. Dann hätten die Implementierungvorgaben eine konforme Implementierung verhindert, die das Problem auch unter einem schweizerdeutschen Locale umgeht, obwohl es technisch kein Hindernis gibt (Stichwort: XkbOptions). Da ein solches Sorgenkind noch auftauchen kann wäre es sinnvoll, die Referenz von implementierungspezifischem Ballast zu befreien. Andreas
Re: [Neo] Neo und Kyrillisch
Unter Linux z.B. könnte man den Kyrillisch-Modus entweder als neue (intern 9. und 10.) Ebenen einführen oder als eigene »Gruppe«. Für die Ebenen bräuchte man einen neuen X-Modifier – Mod2 (was momentan Mod4-Lock ist, den man dann anders implementieren müsste und nicht mehr per Mod4+Mod4 deaktivieren könnte) oder Mod4, das aber für die Windows-Tasten steht und nicht angetastet werden sollte, da viele Nutzer die für eigene Zweck einsetzen. Es gäbe auch eine Möglichkeit, ohne eine zusätzliche Gruppe und ohne zusätzlichen X-Modifier auszukommen: Neo spezifiziert nämlich nicht, wie die Locks miteinander kombinieren. Man könnte also mit CapsLock+Mod4Lock in einen Modus wechseln, der neue Ebenen bereitstellt. Eine eigene Gruppe ist einfacher, aber unter X sind nur höchstens vier Gruppen möglich, und manche Leute nutzen die auch (z.B. Andreas in seinem monolithischen xkb-Treiber). In einem modularen Treiber liegen die Dinge anders als in einem monolithischen: Dort kann der Anwender die gewünschten Gruppen wählen, der Entwickler muss nicht alles entscheiden und fest einbauen. Andreas
Re: [Neo] KP_-Varianten: Referenz vs. xkbmap und xmodmap
Dass der Schreiber kein Deutscher ist, ist jedoch nicht zu erwarten. Was ist mit Schweizern, Liechtensteinern, Österreichern und deutschprachigen Belgiern? Keine Sorge, es geht mir nicht Wortklauberei, die Formulierung ist aber einfach zu geeignet, um sie nicht als Aufhänger für Folgendes zu gebrauchen: Einerseits gibt es auf Schweizer Tastaturen – das war mir bislang garnicht klar – KP_Decimal, nicht aber KP_Seperator. Insofern ist die in diesem Thread geäußerte Behauptung, auf «QWERTZ» gäbe es nur Letzteres, falsch. Andererseits erzeugt OpenOffice mit einem de_CH-Locale aus KP_Seperator einen Punkt, wodurch der Ebene 4- Zifferblock nur eingeschränkt funktioniert. Die Verbannung von KP_Decimal aus Neo könnte also Folgen für potenzielle Benutzer haben, und die OpenOffice-Probleme sind trotzdem nicht behoben. Vorrausgesetzt, man betrachtet Neo als Belegung für Deutsch, und nicht als Belegung für Deutschland. Wenn es nach mir ginge, würde ich dem period und komma auf dem echten, KP_Decimal und KP_Seperator auf dem Ebene 4-Ziffernblock verwenden. Bei letzterem liegen die Ebene 1-Alternativen nämlich bequem erreichbar, zudem bleibt dann auch auf Tastaturen ohne echten Ziffernblock jede keysym verfügbar. Andreas
Re: [Neo] xkbmap seltsam?
Aha, gut zu wissen. Ich signalisiere hiermit Interesse. Wo finde ich dein .xkb? Im SVN gerade war ich mit Blindheit geschlagen. Der monolithische Treiber ist ein Privatprojekt und nicht unter SVN. Du findest ihn hier: http://wettstae.home.solnet.ch/neo_ch_de_us.xkb.gz Andreas
Re: [Neo] xkbmap seltsam?
3. Ich fände es eigentlich besser, wenn statt der Typen EIGHT_LEVEL_NEO_LOCKS_QUARTERALPHABETIC und EIGHT_LEVEL_NEO_LOCKS andere, besser an Neo angepasste Typen definiert würden (da wir sie ohnehin extra einführen müssen). Je Neo-spezifischer die Typen sind, desto weniger sind sie für andere Layouts wiederverwendbar. Wenn man eine Aufnahme ins offizielle xkeyboard-config anstrebt ist das durchaus ein Thema. Nur sechs Ebenen (wie in Neo) Die tote Taste 1 hat sieben Ebenen. Das würde das Anpassen eines eigenen Neo über eine .Xmodmap (für Leute ohne Rootrechte oder wenn sie nicht im xkb rumschreiben möchten) einfacher und logischer machen. Man braucht keine root-Rechte um den offiziellen xkb-Treiber zu verwenden. Zum (nichttrivalen) Anpassen kann man mit xkbcomp ein .xkb-File erzeugen und das dann nach Gusto anpassen. Für einfache Anpassungen reichten vielleicht schon die angebotenen Optionen. In dem Zusammenhang muss ich natürlich wieder meinen monolithischen Treiber ins Gespräch bringen. Dort ist die komplette Belegung in einem .xkb-File, alle Modifikatoren sind reell (Neo-Mod3=X-Mod3, Neo-Mod4=X-Mod4) und die Levels sind wie die Ebenen nummeriert. Zum rumexperimentieren ist das meiner Meinung nach die beste Option. 4. Wozu wird in symbols/level5 der X-Mod2 belegt? Damit Mod4-Lock durch Mod4+Mod4, aber nicht durch ein einfaches Mod4 gelöst wird. Dazu der Zustand «Mod4 gelockt» sich vom Zustand «Mod4 gedrückt» unterscheiden. Wenn du eine Idee hast wie man das ohne einen zusätzlichen reellen X-Modifikator hinbekommt wäre das natürlich prima. Andreas
