Re: [Neo] Neo3 Skripte
> > Du brauchst als erstes einen Korpus, > > Ich habe N-grame, geht das auch? Ja, N-gramme genügen. Andreas
Re: [Neo] Neo3 Skripte
> was ist der jetztige stand der Neo3 Skripte? An meinem Optimierer hat sich in letzter Zeit nicht viel getan. Du findest ihn unter https://sites.google.com/site/ausderneowelt > Ich möchte eine Slowenische Variante von Neo machen und die Skripte (oder gar > ein HOWTO) würde mir da sehr helfen :] Du brauchst als erstes einen Korpus, dann musst du dir überlegen, welche Zeichen eine eigene Taste bekommen, deren Lage optimiert werden soll. Bei meinem Optimierer ist eine Anleitung dabei, bei der ich eben einen Anhang «Zeichen in der Belegung verändern» ergänzt habe. Ich hoffe, damit genügt die Anleitung als HOWTO. Andreas
Re: [Neo] [ticket] #362: h mit Breve (ḫ U+1E2B) funktioniert (fast ausschliesslich) nicht
> > IIRC sind unter Linux einfach alle Compose-Sequenzen kaputt, in denen > > Mod4 vorkommt. Da war doch irgendwas … > > Ab libX11 1.5 funktionieren sie endlich, siehe auch Und selbst wenn «Debian Testing» ein älteres libX11 verwenden sollte: Dieser Bug spielt für dieses Ticket keine Rolle. Er hat nur dann zugeschlagen, wenn Mod4 innerhalb einer Compose-Sequenz gedrückt wurde. Hier wird Mod4 vor der Compose-Sequenz gedrückt, denn diese beginnt erst mit dem Druck auf T3. Oder spricht ka’imi von einem anderen Problem? 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] 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] 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] Qwpr layout
Hello Jameson, by chance, I was browsing around the Colemak site yesterday, and saw your «Dead keys and xkb — oh my.» post. As I have no Colemak account, I could not comment, but now I have the opportunity: Do not implement dead keys as XKB levels or groups. Use the Compose mechanism in libX11. Searching the web for «.XCompose» should give you sufficient information to get going. Regards, 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] 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] i3 & Neo: Alt- und Win-Taste funktionieren nicht
> Deswegen bleibt unklar, was die genaue Ursache war. Ich tippe auf > Hardware. Andererseits erinnern einige deiner Beobachtungen (OpenSUSE, KDE, Alt geht nicht) denen in Ticket #256. Kannst du Pascals Beobachtung mit xev in diesem Ticket reproduzieren? Gibt es noch andere OpenSUSE-KDE- Benutzer hier? Andreas
Re: [Neo] Kein mod4/mod6 mit evdev unter Lubuntu 12.04 LTS
> Jetzt frage ich mich, warum xubuntu 12 dieses 94/108 => 203, 23 macht und > lubuntu 12 94/108 => 108,108 bzw Nix. Wenn eine keysym auf mehreren Tasten liegt ist die Zuordnung keysym -> keycode nicht eindeutig. Deshalb kann bei XKeysymToKeycode eine andere als die gedrückte Taste stehen. Für evdev: = 23; = 108; = 94; Tab hat ISO_Level5_Lock, die <-Taste und rechte Alt-Taste haben ISO_Level5_Lock und ISO_Level5_Shift. > Ich habe die aktualisierte xkbmap runtergezogen und zuletzt noch den > kompletten > Baum /usr/share/X11/xkb/ vom funktionierenden Xubuntu 12 zum Lubuntu 12 > übertragen. Nützt nichts. Wenn du das nicht geschrieben hättest würde ich sagen, dass du auf Xubuntu die Änderungen von der Neo-Seite übernommen hast, auf Lubuntu nicht, denn = 203; sollte eigentlich in der Version von xkeyboard-config noch nichts mit Level5 zu tun haben. Merkwürdig. Im übrigen kannst du dich hier auf's CC setzen: https://bugs.freedesktop.org/show_bug.cgi?id=50935 Andreas
Re: [Neo] vim und cscope-Erweiterung: Tastatürkürzel Strg + \ funktioniert nicht
> Wie gesagt: Bei mir spielte es keine Rolle, in welcher Reihenfolge ich > Strg und Mod3 gedrückt habe. Hast du autorepeat auf der rechten Mod3-Taste abgeschaltet? Dass sollte zwar automatisch passieren, tut es meines Wissens aber noch immer nicht¹. Man muss mit «xset -r keycode» nachhelfen. Andreas ¹ https://bugs.freedesktop.org/show_bug.cgi?id=9796
Re: [Neo] vim und cscope-Erweiterung: Tastatürkürzel Strg + \ funktioniert nicht
> Verrückt: Das -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] vim und cscope-Erweiterung: Tastatürkürzel Strg + \ funktioniert nicht
> Hm, bei mir tritt das von Paul beschriebene Verhalten auch auf: Wenn ich > + oder + drücke > (Reihenfolge egal), wird das unter dem Cursor befindliche Wort gesucht. > Ansonsten passiert mir das oft aus Versehen, und zwar mit der Rautetaste: # Habt ihr beiden ausser Neo noch ein "normales" deutsches Layout in der Belegung, vielleicht gar als primäres Layout? Spiel es eine Rolle, ob man erst Strg und dann Mod3 rechts drückt oder es umgekehrt macht? Andreas
Re: [Neo] Ahnung von xkb gesucht
> – Modifier (Mod3, Mod4, Ctrl, Alt) auf andere Tasten legen
Modifier sind weitgehend ganz normale Belegungen:
Shift ist keysym Shift_L und Shift_R
Mod3 ist keysym ISO_Level3_Shift
Mod4 ist keysym ISO_Level5_Shift
Mod4-Lock ist keysym ISO_Level5_Lock
Alt ist keysym Alt_L und Alt_R
Meta ist keysym Meta_L und Meta_R
Ctrl ist keysym Control_L und Control_R
Super ist keysym Super_L und Super_R
Mod4 und Mod4-Lock sind allerdings etwas schwieriger, siehe
xkb/symbols/level5.
Es gibt schon ziemlich viele Optionen, schau mal in
xkb/symbols/{level3,level5,shift,ctrl,altwin,capslock}. Für persönliche
Zwecke könntest du Umbelegungen, wie sie in diesen Files gemacht werden,
direkt in dein Hauptlayout in xkb/symbols/truly stecken.
> – die ”international“-Tasten der 109er Truly belegen, also die, die auf
> Neo noch kein Keysym haben; insbesondere hätte ich gerne die linke
> Leertaste als Shift
Mit «xev» findest du den keycode (eine Zahl zwischen 8 und 255) heraus.
Mit «xkbcomp :0 aktuell.xkb» kannst du dir die aktuelle Belegung in
«aktuell.xkb» ausgeben lassen. Darin gibt es Zeilen der Form
= Zahl;
Das BLAH zu deinem keycode ist der Name der Taste. Dieser Name ist das,
womit in xkb/symbols/* die zu belegende Taste bezeichnet wird.
Übrigens, statt mit dem ganzen Wust in xkb/* zu arbeiten, kannst du auch
aktuell.xkb direkt anpassen und mit «xkbcomp aktuell.xkb :0» laden. Das
ist einfacher, aber weniger flexibel.
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] Kriterien für Optimierer
> 3. Sind die ganzen Kriterien auch irgendwo ausgeschrieben zu finden > (wenn ja wo?) oder sind die quasi nur in der Config-Datei? In der Anleitung zu meinem Optimierer sind die dort verwendeten Kriterien (einschliesslich der Zahlenwerte) beschrieben (siehe https://sites.google.com/site/ausderneowelt/). Seit deinen damaligen Versuchen ist nur das «Verwechslungspotenzial» neu, und wahrscheinlich entbehrlich. > 4. Ich hätte einen recht flotten Server (i7 2700K (4 Kerne/8 Threads), > 16GB RAM, GNU/Linux) zur relativ freien Verfügung und könnte darauf die > eine oder andere kommerzielle Optimierungssoftware zum Laufen bekommen, > falls eine kostenlose akademische Lizenz zur Verfügung steht. Bei > kostenpflichtigen könnte ich mich schlau machen. Ich denke, die > Entwicklung kann ich mit akademischem Interesse rechtfertigen. Besteht > an so was Bedarf? Ich glaube nicht, dass die eigentliche Optimierung noch ein Problem ist. Die Kriterien sind das Problem. 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
> 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] 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] neo und stumpwm
> CLX, was quasi die XLib für Common Lisp ist, kennt die XKB-Erweiterung > einfach nicht. Das ist gut zu wissen. Wenn CLX das dem Server auch sagt, dann sollte die Gruppenumschaltung mit einem der Modifier Mod1-Mod5 gemacht werden, nämlich dem, der einer mit Mode_switch belegten Taste zugeordnet ist. Damit sollten bis zu vier Ebenen möglich sein. code-state->key in input.lisp scheint im Gegesatz zu keycode->character code-state->auch vier Ebenen vorzusehen. Wenn man ein halbwegs neues xkeyboard-config und ein xkbcomp mit Version vor 1.2.4 hat, funktionierten die Compartibility Modifiers leider nicht korrekt, dann bleiben nur noch zwei Ebenen fürs Anwendungen, die nur das Core Protocol unterstützen. AdNW.sh (und neo.sh) hat eine Option -szd, mit der man erreichen kann, dass aus Sicht des Clients alle ASCII-Zeichen, die Umlaute, die Steuerzeichen und ein paar keysyms mehr auf Ebene 1 und 2 liegen. Das sollte für praktische Zwecke reichen. Man muss aber noch rausfinden, was man tun muss, dass die Modifier auch von StumpWM als Modifier behandelt werden. 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: : 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
> Ich habe die Umgebungsvariablen so in `~/.xinputrc` gesetzt. Auf manchen Systemen ist das richtige File ~/.xinput.d/ (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
> 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
> 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
> 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] 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] Howto: Write reversed Questionmark
> : "⸮" 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] Modifierpositionen
Noch eine Variante für Shift: Ich habe seit etwas über einem Jahr Shift links auf QWERTZ-< liegen. Für «Aus der Neo-Welt» ist Shift links wichtiger rechts, weil ungefähr 2/3 der Grossbuchstaben von der rechten Hand angeschlagen werden. Ich empfinde QWERTZ-< eigentlich als gut gelegen, aber das Umgewöhnen ist mir trotzdem schwer gefallen. Das liegt vielleicht auch daran, dass ich vorher Mod3 dort hatte jetzt einfach Belegung vertauscht habe. Unterm Strich weiss ich nicht, ob es sich gelohnt hat. > Effchen hat außerdem noch folgenden unkonventionellen Vorschlag gemacht: Die > Leertaste zu Shift machen und das Leerzeichen auf QWERTZ-V legen. Mit XKB könnte man die Leertaste zu Leerzeichen und Shift gleichzeitig machen. Viele Grossbuchstaben kommen ja nach einem Leerzeichen, das Shift gäb's dafür umsonst. Allerdings muss man fix sein und den Buchstaben eingeben bevor das Autorepeat der Leertaste einsetzt. Und ob man das überhaupt lernen kann ist auch noch die Frage. 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] 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?
> 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] 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] 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.
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
[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
> Das klingt klasse! Das Gefühl hatte ich nämlich auch schon, dachte aber, dass > es wohl eher eine fixe Idee ist. Aber nachdem du sie nun bereits durchdacht > hast, sollte ich sie wohl mal implementieren :) Bei mir war es ein Überlegung, kein Gefühl, bis auf einmal, als ich «debug» getippt habe – das sind bei meiner Belegung vier Handwechsel, d, b und g liegen auf aber dem gleichen Finger. Ich tippe oft «debug», und meistens fällt mir nichts dabei auf. > Damit könnte ich also einfach den Code wiederverwenden. Allerdings müsste > dann > alles über trigramme laufen, und die sind nicht wirklich schnell (weil viel > zu > viele…). Wichtiger als die Wiederverwertung von Code ist, dass man nicht zu viele Parameter einführt. Die wachsen einem auch ohne Trigramme schon über den Kopf. Die Rechenzeit geht allerdings in der Tat merklich rauf. Vielleicht kann man Abschätzungen machen. Wenn man die Belegung zweier Tasten vertauscht und die Aufwandsänderung aufgrund von Einzeltastengewichten und Bigrammen berechnet hat, könnte man so vielleicht beurteilen, ob die Trigramme am Ergebnis (Verbesserung oder Verschlechterung) überhaupt noch etwas ändern können. Eine gute, schnelle Abschätzung zu machen ist vermutlich nicht einfach. Mit C++ kann man die Trigramme auch mit Gewalt noch in akzeptabler Zeit behandeln, daher bin ich bisher bei der Holzhammermethode geblieben. > > 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. > > Ich hoffe, dass da die Auswirkungen ausreichend gering sind. Nur wenn die 2. > Stelle (fast) wegfällt, sollte die 3. viel ausmachen. Zumindest, wenn die > Auswirkungen ausreichend schnell fallen. Ich denke, wenn man mit QWERTZ «oj.» tippt hat den Paradefall: Zwei harmlose Bigramme, ein günstig gelegener mittlere Buchstabe, aber eine «Kollision» mit weitem Sprung zwischen erstem und letztem Zeichen. > Wenn das nicht der Fall sein sollte, > wird das ganze hier *sehr* teuer… aber wenn es sein muss, muss es sein. Das ist «nur» noch eine Verdoppelung der Rechenzeit. > Ich fühle mich gerade in meine Physik-Vorlesungen zurückversetzt: Quadrupole > sind nur dann direkt sichtbar, wenn die Bipole sich aufheben (heißt: Die 2. > Ableitung ist nur relevant, wenn die 1. wegfällt). Und ja, das muss man > trotzdem rechnen… :) Ja, wir machen hier eine Entwicklung des Tippaufwands nach Ordnung der n-Gramme. Wenn wir verlangen, dass die Kosten von allen n-Grammen nichtnegativ sind, muss das sogar konvergieren. Leider sind bei mir manche Kosten negativ… 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] Optimierer und Parameter
> Theoretisch müsste sich dadurch die komplette Bigramm- und > Einzelzeichenrechnung ersetzen lassen, so dass nur noch Trigramme mit den > aktuellen Methoden gerechnet werden müssten (für Handwechsel und > Richtungswechsel). > > Und zumindest mein Optimierer würde wohl nochmal um Faktor 2 schneller > werden :) Ich mache die Bigramm- und Einzelzeichenrechnung vorab und lege die Werte in Tabellen ab wie der, die Björn aufstellen will. Das kannst du doch auch tun, schon jetzt, oder? 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] Weiter mit Vrijbuiter
> genügt als Verdachtsmoment (Arne wieder). Allein diese pauschale Behauptung > brauchen (Arne wieder). Es ist nicht mal zur Sprache gekommen, was eine Ulf, es geht nicht alles um dich. Wenn Arne normale Kollisionen und Shift-Kollisionen zusammenzählt ist das kein Angriff auf NordTast, es ist schlicht eine andere Wahl der Darstellung als du sie verwendest (wenn du ihn darum bittest ändert er sie vielleicht). Wenn Arne unterschiedliche Lagepunkte rausbekommt als du ist das kein persönlicher Vorwurf, sondern schlicht ein Resultat aus dem Feedback zu den Einzeltastengewichten das er gesammelt hat. > Steht das H oben, hat das bestimmte Vorteile, die > Andreas ausgerechnet hat (die aber keineswegs von den Neo-Usern genehmigt > sind und deshalb sehr verdächtig sind, zumindest für Arne), Wenn du das Kriterium meinst, dass man bei Bigrammen abseits der Grundlinie das Einzeltastengewicht der zweiten Taste effektiv verringert: Das hat Arne längst in seinem Optimierer. Es wäre mir recht wenn du Arne nicht vergraulst, sonst macht er am Ende einen weiteren Neo-Fork auf, und dann muss ich die ganzen Control-XVC wasweissich Sonderwünsche in meinen eigenen Optimierer einbauen… > Was soll man stattdessen tun? Es ist besser, Erkenntnisse aus den > Vrijbuiter-basteleien zu Kenntnis zu nehmen, und sie in die > Optimierungsalgorithmen einfließen zu lassen. Ein Teil des Gebastels (Kollision «ph» eliminieren, Punkt und Komma tauschen) würde vielleicht mit einem anderen Korpus nicht nötig sein. Ansonsten ist es schwierig: Ich sehe nicht, wie ich das Gebastel (zum Beispiel den Spaltentausch) abstrahieren und in Bewertungskriterien übersetzen kann. Andere Einzeltastengewichte? 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] Ein Knaller! (war: 1-, 2-, 3-gramme erstellen unter Linux)
> Wobei mir da gerade noch auffällt: Wie genau behandelst du Großschreibung > wirklich sauber? Für die Einzeltastenwertung veranschlage ich für Shift einfach die Kosten für den zusätzlichen Tastendruck. Das spielt nur dann eine Rolle, wenn Shift links und rechts nicht symmetrisch sind, und daher die linke und rechte Shifttaste unterschiedlich viel kosten. Die Bigrammwertung mache ich so: Ich gehe von Bigrammkosten für alle Tastenpaare (i,j) aus. Will ich dann «Ab» bewerten, und A liegt auf Taste i, das Shift gegenüber auf Taste k, und b auf Taste j, dann veranschlage ich die Summe Kosten für das Bigramm (i,j) und (k,j). Für «aB», falls l die Shifttaste gegenüber von Taste j ist, veranschlage ich die Summe Kosten für das Bigramm (i,j) und (i,l), für «AB» schliesslich (i,j)+(k,j)+(i,l). > - Die Kollision shift-erster Buchstabe stärker, weil das Shift meist schon > etwas früher gelöst wird als der Buchstabe (zumindest bei mir). Ich hatte sowas in der Art mal, hab's aber bei einer Codevereinfachung verloren. Grundsätzlich ist es sinnvoll, Shift-Kollisionen anders zu gewichten als normale; im Fall «Ab» eher schwächer, im Fall «aB» eher stärker, aus dem von dir genannten Grund. 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] 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] 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] 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] 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] 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] 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] 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
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] 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 überlege gerade, ob es sinnvoll wäre, noch die Streuung der Werte > miteinzubeziehen, so dass es möglichst wenige worst case Worte gibt (sowas > wie „Völkerball“ in Neo). Meinst du, dass man sich um einzelne Worte scheren soll? Klar, wenn ein wüstes Wort in einem Text dauernd vorkommt ist das vielleicht lästig, aber da kann man sich mit einem guten Editor weiterhelfen. Auf der Ebene ganzer Texte vermute ich, dass schon die Minimierung des Aufwands die Steuung klein macht: Die Häufigkeit häufiger Zeichen und Bigramme sollte eigentlich auch eine großen absolute Streuung haben. Genauer hypothetisiert, wenn ein Zeichen in einem Text der Länge n im Mittel m mal auftaucht erwarte ich als Vulgärstatistiker, dass die Varianz der Häufigkeit des Zeiches auch ungefähr m ist (Was zu zeigen wäre, schliesslich geht es hier nicht um radioaktiven Zerfall…). Da Optimierung den häufigen Zeichen und Bigrammen bevorzugt Positionen mit kleinen Gewicht zuweist wird mit dem mittleren Aufwand auch dessen Varianz minimiert. 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] 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
> 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] 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
> 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] Kriterien für ein optimiertes Layout
> Ich brauche allerdings sinnvolle Kostenfaktoren, sonst ist das ganze Modell > sinnlos. Hier ein paar Links zum Thema: http://mkweb.bcgsc.ca/carpalx/?typing_effort http://www.michaelcapewell.com/projects/keyboard/layout_capewell.htm http://klausler.com/evolved.html http://forschung.goebel-consult.de/de-ergo/rohmert/Rohmert.html Zusammengefasst: Fingerkollisionen sind schlecht. Jenseits dieser Aussage herrscht Uneinigkeit, selbst bei qualitativen Fragen wie der, ob viele Handwechsel gut sind oder nicht. Zeitmessungen geben je nach Versuchsanordnung verschiedene Ergebnisse. Vielleicht sind Zeitmessungen trotzdem zu was nütze, vielleicht auch Statistiken zu Tippfehlern. Zum Beispiel wäre es interessant zu sehen, ob die Häufigkeit, mit der aufeinanderfolgende Buchstaben vertauscht werden einen statistischen Zusammenhang damit hat, ob die Buchstaben auf verschiedenen Händen liegen oder nicht. Die Kriterien in meinen Optimierer sind derzeit ähnlich wie bei Klauslers zweitem Versuch (einfach deshalb, weil Ulf die in seinem Bewertungsprogamm verwendet hat). 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] Woher den Platz für Modifikatortasten nehmen ?
> Also ich kenne keins – genau deshalb habe ich mich ja auch gewundert, warum > Andreas sein Experiment mit der q- und nicht der ß-Taste gemacht hat. Q ist seltener als ß, außerdem kommt q fast nur im Bigramm qu vor, bei ß hat man dagegen keine so klaren Präferenzen. So weit, so irrelevant; q und ß sind beide so selten, dass der nominelle Vorteil von totem q gegenüber totem ß so nicht ins Gewicht fällt. Letztlich will ich aber eine gewisse Anzahl – sagen wir, zwei – Tasten freibekommen. Ich kann das machen, indem ich mit totem q die Zeichen q, ß und ö erzeuge, oder indem ich mit totem ß die Zeichen ß, ö und ä erzeuge. Die Frage ist also nicht «q oder ß?», sondern «q oder ä?», und ä ist so selten nicht (es macht in deutschen Texten etwa ein halbes Prozent aus). 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
[Neo] Woher den Platz für Modifikatortasten nehmen ?
Hallo miteinander, Einer der Wünsche für eine Neo2 überlegene Tastaturbelegung ist, dass wichtige Modifikatoren besser zu erreichen sind. Dazu muss man die Modifikatoren auf Tasten legen, auf denen jetzt Buchstaben bzw. Punkt und Komma liegen. Wohin mit den verdrängten Zeichen? Die einfachste Lösung ist, schlechter gelegene Tasten oder höhere Ebenen heranzuziehen. Das funktioniert sicher, ist aber langweilig und nicht unbedingt die effizienteste Lösung. Die Alternative ist, ein paar Zeichen mit toten Tasten zu erzeugen (zum Beispiel im Sinne von Karls Quick-Tot-Tasten). Diese Lösung hat drei Haken: a) Man braucht einen passablen Platz für die tote Taste. b) Unter X kann man mit toten Tasten keine Alt- oder Control-Codes generieren. Das heißt, entweder sieht man eine alternative Eingabemöglichkeit vor oder man beschränkt die so erzeugten Zeichen auf Umlaute und andere nicht-ASCII-Zeichen. c) Das System wird fragiler, zumindest unter X: Die Tastatur funktioniert nur wenn Treiber und Compose beide funktionieren, und diese beiden Komponenten sind bei X getrennt. Die Konsequenzen davon sind diesselben wie für b). Man könnte meinen, ein weiterer Haken sei, dass man mehr Anschläge braucht, wenn ein Zeichen per toter Taste statt direkt erzeugt wird. Das ist meistens, aber nicht unbedingt so, siehe unten. Mit b) und c) muss man sich abfinden. Zu a) sehe ich zwei Auswege. 1. Die tote-q-Tastatur: Statt extra eine tote Taste einzuführen tötet man q. Q deshalb, weil es der seltenste Buchstabe ist und noch dazu fast ausschließlich im Bigramm qu auftaucht. In .XCompose sieht die tote-q-Tastatur zum Beispiel so aus: ~Ctrl ~Alt : q ~Ctrl ~Alt : Q ~Ctrl ~Alt : "qu" ~Ctrl ~Alt : "qU" ~Ctrl ~Alt : "Qu" ~Ctrl ~Alt : "QU" ~Ctrl ~Alt : odiaeresis ~Ctrl ~Alt : Odiaeresis ~Ctrl ~Alt : ssharp ~Ctrl ~Alt : "ẞ" ~Ctrl ~Alt : "ẞ" Durch ~Ctrl ~Alt erreicht man, dass Control-q und Alt-q noch funktionieren; die Sequenzen mit u stellen sicher, dass das Bigramm qu eingegeben werden kann, als wäre q noch lebendig; ein einzelnes q bekommt man durch einen Doppeltanschlag. Der eigentliche Zweck des toten q ist im Beispiel oben die Erzeugung von ö und ß als Compose-Sequenzen. Wenn aus irgendeinem Grund Compose nicht funktioniert (zum Beispiel in Applikationen, die Compose nicht unterstützen) bleibt in der Regel das q lebendig; man verliert zwar ein paar Umlaute, aber hat noch immer ein bedienbares System. Ich habe jetzt drei Monate mit totem q gelebt nur zwei Ausnahmen von der Regel gefunden (rdesktop und ein Derivat von ICA Client); für beide Programme kann mit der Umgebungsvariable XCOMPOSEFILE das q am Leben halten (Kommandozeile «XCOMPOSEFILE= rdesktop» oder ähnlich). Insgesamt ist die tote-q-Lösung gangbar. Lernbarkeit: An den Doppeltanschlag von q bei der Bedienung von Programmen (die q für Quit verwenden) habe ich mich rasch gewöhnt. Die Gewöhnung beim Schreiben geht langsamer. Ich glaube das liegt daran, dass ich wenig Deutsch und daher wenig ö und ß schreibe. An die Lage der Umlaute bei Neo hatte ich mich nach drei Monaten genausowenig gewöhnt. 2. Modifikatoren als tote Tasten benutzen. Einen Modifikator zu drücken und gleich wieder loszulassen hat normalerweise keine Funktion; die Idee ist, diesen Vorgang wie den Druck einer toten Taste zu behandeln. Der AHK-Treiber nutzt diese Idee in der Implementierung des Einhand-Modus. Windows ist also kein Problem. Mit XKB hingegen ist die Idee nicht umsetzbar. Sie lässt sich aber mit Eingabemethoden realisieren. Im Neoland ist die Eingabemethode der Wahl der Compose-Mechanismus, wobei wir also wieder bei den toten Tasten sind. Normalerweise ignoriert Compose Modifikatoren völlig. Mit kleinen Sourcecodeänderungen kann man aber mit der Definition : ssharp mit Mod3 ein ß eingeben. Mit einem einzigen Anschlag, wohlgemerkt. Zu den üblichen Einschränkungen der toten Tasten kommen noch folgende Bedenken: - Ob Compose jemals wie gewünscht erweitert wird ist offen. Ein Patch ist eingereicht (https://bugs.freedesktop.org/show_bug.cgi?id=26705), aber das heißt nicht viel. Auch im günstigsten Fall wird es Jahre dauern, bis die Änderung sich allgemein verbreitet hat. - Die Lösung funktioniert nicht mit allen Programmen, auch nicht mit allen Compose-tauglichen. Beispielsweise versagen xterm und emacs mit Xaw; urxvt, firefox, inkscape, OpenOffice, kword, dillo, gitk und emacs mit GTK-Widgets funktionieren hingegen. Alles in allem ist das Bild aber besser als ich gehofft hatte. Ich habe auch mit einen weiteren Eingabemethode, IBus, experimentiert. Ich habe nur kleines Demo, nichts, was den Compose-Mechanismus der Xlib auch nur annähernd nachbildet; es geht nur
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?
> 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?
> 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 Gesa
Re: [Neo] [ticket] #189: X Error of failed request: BadValue (integer parameter out of range for operation)
> Bei bestimmten Kombination der Mod3- und Mod4-Tasten lassen sich einige > Zeichen der 6. Ebene nicht eingeben. Das liegt vermutlich an deiner Tastatur. Siehe: http://wiki.neo-layout.org/wiki/Hardwareprobleme Andreas
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] Gemischt-ganzzahlig-linearer Optimierungsansatz
> Negatives in der Klammer macht aber nichts, da für jede > Buchstabenkombination mindestens einmal die Klammer positiv wird (jeder > Buchstabe muss einer Taste zugewiesen werden), und z(ij) mindestens > diesen Wert erreichen muss Bei n Tasten und Zeichen ist in den n² Termen in der Summe in (7) bei (n-1)² Termen die Klammer -1, bei 2n-1 Null, und bei einem Eins (natürlich vorausgesetzt die x erfüllen ihre Nebenbedingung). Die rechte Seite von (7) wird (wenn wir exotische Bewertungschemata beiseite lassen) also negativ sein. Zusammen mit (1) und (12) ist dann im Optimum z(ij) = 0. Oder? Meinem Verständis nach richtig wäre es, (12) zu streichen, dafür aus (7) eine Gleichung zu machen und die Klammer durch Größen b zu ersetzen für die gilt: b(itju) ≥ x(it)+x(ju)-1 b(itju) ≥ 0 Für n = 32 sind das mehr als zwei Millionen Nebenbedingungen. Andreas
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
> > Interessant finde ich Gleichung (3). Kann man diese Bedingung > > verallgemeinern? Man stelle sich vor, eine Tastatur mit zwei e's, von > > denen man jeweils das bequemere tippt? > Das ist in der Form nicht vorgesehen, das würde auch einige andere > Nebenbedingungen ziemlich stark beeinträchtigen. Man kann solche Alternativen wohl sowieso nicht alleine mit Bigrammhäufigkeiten richtig modellieren. Ist auch nicht so wichtig, es wäre vemutlich auch zu schwer zu lernen. Andreas
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
> Das bis hierher entwickelte gemischt-ganzzahlige lineare > Optimierungsmodell habe ich mal an die Mail angehängt, falls sich jemand > mit solchen Modellen auskennt, kann er ja mal einen Blick darauf > werfen. Danke. Ich kenn mich zwar nicht aus, habe aber trotzdem einen Blick darauf geworfen. Auf der rechten Seite von (7) müssen x'e statt z's stehen, für die z's passen die Indices nicht. Zudem kann in der Klammer etwas negatives stehen; ist das ein Problem? Sollte man nicht ein Produkt zweier x'e statt z+z-1 (bzw. x+x-1) haben, oder ist das dann nicht mehr gemischt-ganzzahlig linear? Interessant finde ich Gleichung (3). Kann man diese Bedingung verallgemeinern? Man stelle sich vor, eine Tastatur mit zwei e's, von denen man jeweils das bequemere tippt? 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
