Re: [Neo] Gedanken zu quot; Programm zum Konvertieren von Text zum praktischen Testen von neuen Layouts?quot;
Karl Köckemann wrote: Kann man davon ausgehen, dass, wer bereit ist, sich auf eine Tastenbelegung mit 10 veränderten Qwertz-Tasten (5 Tastenpaare) einzulassen, besser gleich auf eine komplett neue Belegung umsteigt? Denke ich, ja. Deswegen habe ich hier auch mal die Einzel- und Doppelvertauschung gepostet. Drei wäre übrigens das hier: qwört zundpü asofg hjkleä yxcvb im,.- # 3.82015149667 billion total penalty compared to notime-noeffort # 4.90888451717 mean key position cost in file 1gramme.txt # 6.03403605792 % finger repeats in file 2gramme.txt # 13.4160655401 million keystrokes disbalance of the fingers # 0.283886124669 % finger repeats top to bottom or vice versa # 44.5838600593 % of trigrams have no handswitching (uppercase ignored) # 0.434066727637 billion (rows/dist)² to cross # 0.102622512969 hand disbalance. Left: 0.397377487031 %, Right: 0.602622512969 % Fazit: Mit den Vertauschungen lässt sich zwar viel erreichen, aber ein optimales Layout sieht anders aus. Die Gewichtung der einzelnen Kosten ist dabei allerdings der absolute Knackpunkt, da hier z.B. v.a. die Zeilenwechsel minimiert wurden. Liebe Grüße, Arne
Re: [Neo] Gedanken zu Programm zum Konvertieren von Text zum praktischen Testen von neuen Layouts?
Peter Karp wrote: Jetzt schaue ich und sehe, dass mit den derzeitigen Gewichtungen als zweiter Tausch das Optimierungs-Skript d gegen o tauscht. Meinst Du, dass das tatsächlich der zweitwichtigste / effektivste Tausch ist Das Skript prüft gegen sehr viel mehr Parameter als nur „wer ist am häufigsten“ und „wie gut ist die Einzeltaste zu erreichen“. Daher: Nach den aktuellen Parametern ist das die beste Vertauschung, ja. Trotzdem würde es mich wundern, wenn das häufig genutzte n auf der nicht sooo dollen Position (gut, sooo schlecht ist sie auch nicht) bleiben wird und nicht ziemlich schnell in die Grundreihe rutscht? Vor allem muss auch das j aus der Grundreihe verschwinden. Bei den 5 wichtigsten / effektivsten Tauschpaaren, bin ich mir sehr sicher, dass das dabei sein muss und auch recht bald in einer Optimierungsreihenfolge auf der Grundreihe Platz machen muss. Meinst Du das auch? Ich Maße mir nicht an, alle Bigramme und Trigramme der deutschen Sprache im Kopf zu haben. Genau deswegen habe ich den Optimierer geschrieben (sonst hätte ich auch gleich von Hand designen können). 1) Wie findet man eine gute Kostenverteilung? Das ist genau die wichtigste Frage. Sie fragt nämlich direkt: Was ist gutes Tippen. Das ist die grundlegende Vorbedingung um irgendwelche Kosten festzulegen. Wenn man zustimmt, dass ein Text am bequemsten zu tippen wäre, wenn man nur die 8 Finger in der Grundstellung bewegen müsste, so sollten die ersten 8 1-Gramme in der Grundstellung landen. Dem Programm könnte ich also schon vorschreiben, dass die Variation dieser Buchstaben nur noch in der Grundreihe zu erfolgen hat! Wenn du das willst, nimm’ Neo 2. Das macht genau das. Bei dem Optimierer geht es dagegen darum, komplexere Einflüsse zu finden und in die Optimierung einfließen zu lassen. Wer kann optimalen Tippkomfort beurteilen? Nur der Mensch. Daraus folgt, dass man zwingend Tippexperimente mit Leuten machen muss -- ähnlich wie bei psychophysikalischen Experimenten, wenn es um Sinneswahrnehmungen geht. Das machen wir bereits. Siehe erste Nachricht in diesem Thread. Genau dafür sind die Beispieltexte da. Liebe Grüße, Arne
[Neo] Warschau (was: Re: Langes s)
Hallo allerseits, Florian Janßen ſchrieb am 12.05.2010 11:27 Uhr: Als alter Segler kenne ich natürlich „Wahrschau“ im Sinne von „Vorsicht“, „Hab’ acht“ meist mit der Bedeutung:„Kopf runter“ :) Ach ja, in dem Kontext wird das ja auch gerne benutzt :). Ich dachte auch mehr an die ›Südländer‹ hier auf der Liste … obwohl, man kann ja auch auf dem Bodensee segeln :). Martime Grüße, Dennis-ſ
Re: [Neo] Wie erstellt man eine eigene Tastaturbelegung?
Moin Klaus, Klaus Weidinger ſchrieb am 12.05.2010 18:34 Uhr: Ich würde gerne wissen, wie man ein eigenes Tastaturlayout erstellt. Mit Geduld und Spucke ;). Natürlich sollte man sich zuerst über die Position aller Zeichen Gedanken machen, Das ist wohl der mit Abstand schwierigste Teil; bei Neo 2 haben wir sehr lange (und engagiert) über viele Kleinigkeiten diskutieren müssen, bis wir da einen Konsens gefunden haben, von daher sollte man diesen Punkt nicht unterschätzen, da es allgemein doch sehr zu zu bedenken (bzw. zu entscheiden) gibt. Wenn man einen Treiber für sich selbst erstellt, muss man alerdings nicht auf die Meinungen anderer Rücksicht nehmen, also hängt das davon ab, wie perfektionistisch Du bist ;). aber was kommt dann? A ja, Dich interessiert also mehr der ›technische‹ Aspekt der Treibererstellung. Und wie zeitaufwändig ist es ungefähr, wenn man sich nur für den Eigenbedarf ein Layout erstellen will (muss also nicht auf allen Systemen laufen). Die meisten Neo-Treiber sind im Kern mehr oder minder kompliziert ausſehende Textdateien, die man als ›Blaupause‹ für eigene Entwürfe und Anpassungen nehmen kann, man muss sie einfach nur an der entscheidenen Stelle ändern; wobei Neo mit 6 Ebenen (und zusätzlichen Kompose-Sequenzen) recht komplex ist, so dass Dein eigener Treiber wohl eher einfacher ausfallen wird. Als Einstiegspunkt würde ich Dir erstmal unsere entsprechende Seite im Wiki http://wiki.neo-layout.org/wiki/Treiber-Know-How empfehlen, und dann … ¡sei mutig!, um die Wikipedia zu zitieren :). Danke schonmal vorab, Bitte entschuldige, das Du erst jetzt eine Antwort bekommen hast! Viele Grüße, Dennis
Re: [Neo] Gedanken zu Programm zum Konvertieren von Text zum praktischen Testen von neuen Layouts?
Moin Peter, Peter Karp ſchrieb am 20.05.2010 22:19 Uhr: Man verzeihe den einen oder anderen Vertipper. War ein langer Tag;-) Kein Problem, das kennen wir doch alle :) Viele Grüße, Dennis-ſ
Re: [Neo] Git und Mercurial
Hallo allerseits, Arne Babenhauserheide ſchrieb am 12.05.2010 16:03 Uhr: Ich selbst habe mir inzwischen schon mehrfach mit git bei Standardaufgaben böse in den Fuß geschossen (soweit, dass ich neu klonen musste), mit Mercurial dagegen noch nie. Dann kann ich allerdings gut nachvollziehen, warum Du jetzt Git eher abgeneigt bist, so etwas sollte natürlich definitiv nicht passieren. Ich selbst habe mir erst ein einziges Mal ein Git-Repository so total vermurkst, dass ich mir lieber das letzte Backup neu geklont habe, aber dass war definitiv mir anzulasten – ich war da noch hundertprozentig in der alten SVN-Denke verhaftet und wusste mit einem DVCS noch nicht richtig umzugehen. Und Mercurial bedient sich grundlegend wie Subversion, wenn man im Kopf behält, dass commit nur lokal wirkt und pull/push neue Änderungen holen bzw. rausschicken. Wie bereits gesagt bin ich der Ansicht, das sich Mercurial und Git in der Bedienung nicht so sehr voneinander unterscheiden; und gewisse Schwierigkeiten vom Umstieg von SVN auf ein DVCS sind (leider) einfach nicht zu vermeiden, einfach da sich hier ganz neue Arbeitsabläufe eröffnen. Aber auch Git kann man wie ein SVN bedienen … man kann sogar auf ein SVN zugreifen :). Doch: Das Mercurial Plugin funktioniert auch in die andere Richtung: Klar, das Plugin selbst funktioniert bidirektional und kann die beiden Formate ineinander unwandeln aber es liegt eben nur für hg- und nicht für git-Clients vor (das meinte ich). Mercurial baut auf jedem System auf dem auch git baut […] in Python[…] geschrieben humorDas wäre dann wieder ein Punkt für Git: “Python? That is for children. A Klingon Warrior uses only machine code, keyed in on the front panel switches in raw binary.” ;)/humor Für mich ist seltsamerweise gerade die Datenstruktur ein Grund Mercurial zu nutzen. Ich finde das doch recht witzig, wir finden den selben Aspekt wichtig, aber sind zu genau entgegengesetzten Einschätzungen gekommen. An der Git-Datenstruktur schätze ich, dass sie auf der untersten Ebene recht simpel ist und gleichzeitig jede Redundanz vermeidet – vielleicht sind deshalb die git-Repositories im Allgmeinen die Kleinsten (ja, ich habe hier mal wieder ein git gc vorausgesetzt). Es verwendet zwar auch Patches, speichert sie aber in einem Dateibaum, der bessere Zugriffssemantiken bietet (Festplatten-seeks vermeiden) und nutzt snapshots (wie in Videokomprimierung), um den Zugriff zu beschleunigen. Eigentlich arbeitet Git da recht ähnlich, in den Packfiles gibt es auch unkomprimierte Schnappschüsse, Deltakodierung und Indizierung für einen schnelleren Zugriff. Ich glaube, in dieser Frage werden wir einfach nicht zueinander finden … einigen wir uns darauf, das wir uns uneinig sind :). Arne Babenhauserheide ſchrieb am 18.05.2010 07:42 Uhr: Christian Kluge ſchrieb: 1.7.* ist doch schon seit Ewigkeiten raus Wird aber von den Gentoo-Maintainern noch nicht als stabil betrachtet, deshalb habe ich es nicht. Ich nutze Testversionen nur bei den Sachen, bei denen ich wirklich die neusten Features testen will. Der Rest hat einfach zu laufen, und da vertraue ich auf das Urteil der Maintainer. Und ich würde keinen Distributions-Maintainern glauben, die glauben kompetenter als die eigentlicher Software-Maintainer zu sein ;): “The latest stable Git release is v1.7.1.” (http://git-scm.com/). git checkout -h Ah, darauf warte ich seit Jahren! Dann hat Dir die neue Version doch etwas gebracht, #Friede_Freude_Eierkuche :). Allerdings könnten „-bnew branch → branch“ u.ä. doch etwas ausführlicher sein… “Specifications are for the weak and timid!”¹ ;) – aber inzwischen ist die Git-Dokumentation recht gut ausgebaut (am Anfang war die wohl noch /richtig/ mies im Vergleich zu Mercurial), wobei ich niemanden empfehlen würde, Git oder auch Mercurial ausſchließlich über die Manpages zu lernen. Dafür gibt es einfach viel zu viele, und man kann sich ja wohl kaum alphabetisch durchlesen … besser ist es da, mit einem guten Tutorial anzufangen. Nebenbei: Hast du gemerkt, dass auf einem deutschen System der Großteil der Ausgabe von Mercurial auf Deutsch ist? Erst jetzt, wo Du es sagst :). Wobei ich kein Problem mit Englisch habe, und bei Kommandozeilenbefehlen sogar lieber englischſprachige Manpages lese, einfach weil ich mir dann die Abkürzungen besser merken kann – rm -f steht ja für “remove --force”, und nicht für löschen --erzwingen. Viele Grüße, Dennis-ſ ¹ http://gradha.sdf-eu.org/textos/klingon_programmer.en.html
Re: [Neo] druckvorlage bereinigt
Hallo allerseits, Erik Streb del Toro ſchrieb am 20.05.2010 00:56 Uhr: Die Druckvorlage […] etwas bereinigt. Sehr schön, vielen Dank dafür! Mühsam ernährt sich das Eichhörnchen :) Viele Grüße, Dennis-ſ
Re: [Neo] Git und Mercurial
Dennis Heidsiek wrote: Wie bereits gesagt bin ich der Ansicht, das sich Mercurial und Git in der Bedienung nicht so sehr voneinander unterscheiden; und gewisse Schwierigkeiten vom Umstieg von SVN auf ein DVCS sind (leider) einfach nicht zu vermeiden, einfach da sich hier ganz neue Arbeitsabläufe eröffnen. Der einzige wirkliche Fehler den ich bisher (selbst bei einem Computer-DAU) mit Mercurial erlebt habe, ist zu vergessen zu pushen oder zu pullen (solange keine als experimentell ausgezeichnete Module genutzt wurden). Selbst einen merge habe ich letztens über’s telefon erklaärt, und das komplizierteste war, dass ich kein TortoiseHG nutze, der andere aber schon (finden der richtigen Tasten :) ). (auf der Kommandozeile wäre es noch einfacher gewesen) Aber auch Git kann man wie ein SVN bedienen … man kann sogar auf ein SVN zugreifen :). Wie mit hgsubversion (Mercurial extension die ähnliche Strukturen nutzt wie hg-git) :) Doch: Das Mercurial Plugin funktioniert auch in die andere Richtung: Klar, das Plugin selbst funktioniert bidirektional und kann die beiden Formate ineinander unwandeln aber es liegt eben nur für hg- und nicht für git-Clients vor (das meinte ich). Jupp, aber es ändert nichts wesentliches am workflow (man muss halt einen Mercurial aufrufenden hook in seinem lokalen git repo erstellen :) ). Mercurial baut auf jedem System auf dem auch git baut […] in Python[…] geschrieben humorDas wäre dann wieder ein Punkt für Git: “Python? That is for children. A Klingon Warrior uses only machine code, keyed in on the front panel switches in raw binary.” ;)/humor ;) Ich finde das doch recht witzig, wir finden den selben Aspekt wichtig, aber sind zu genau entgegengesetzten Einschätzungen gekommen. An der Git-Datenstruktur schätze ich, dass sie auf der untersten Ebene recht simpel ist und gleichzeitig jede Redundanz vermeidet – vielleicht sind deshalb die git-Repositories im Allgmeinen die Kleinsten (ja, ich habe hier mal wieder ein git gc vorausgesetzt). Was ich im Gegenzug bei Mercurial schätze ist, dass die Struktur genau für ihre Aufgabe optimiert ist. Sie ist sogar auf Zugriffsstruktur von Dateisystemen optimiert: Daten sind im store in einem Dateibaum, der dem Arbeitsverzeichnis entspricht, weil sich so beim sortierten Auslesen (das machen die meisten Dateisysteme) der Festplattenkopf am wenigsten bewegen muss. Deswegen ist auch bei einem update via Mercurial die Platte sehr viel leiser als bei git (ich höre das deutlich; meine Platte rattert). Und deswegen sind git repos kleiner. hey, und ich kann gerade den Zirkelschluss zu Tastaturbelegungen ziehen: Ein Layout, das nur auf Tastenpositionen und Fingerwiederholungen achtet, hat (bei maximaler Optimierung) gezwungenermaßen bessere Tastenpositionen und weniger Fingerwiederholungen als eins, das zusätzlich beachtet, dass nicht erst ein Finger oben und dann der direkt daneben unten eingesetzt wird. Welches von ihnen besser zum Tippen ist, hängt von der Flexibilität der Finger ab :) Eigentlich arbeitet Git da recht ähnlich, in den Packfiles gibt es auch unkomprimierte Schnappschüsse, Deltakodierung und Indizierung für einen schnelleren Zugriff. Der Unterschied ist halt, dass das bei Mercurial direkt beim committen on- the-fly passiert. Aber sie haben auch beide immer wieder voneinander gelernt – was ich sehr gut finde! Ich glaube, in dieser Frage werden wir einfach nicht zueinander finden … einigen wir uns darauf, das wir uns uneinig sind :). Ich denke, da werden wir nicht drum rum kommen. Immerhin sind wir aber bereits fast an der untersten Ebene (statt „A B ⇒|⇐ B A“ sind wir bei „A macht das so, was ich wegen X besser finde als das, wie B es macht ⇒|⇐ Mir ist aber Y wichtiger als X, und das kann B besser“), so dass die Diskussion, finde ich, fruchtbar und sinnvoll war – und auch einen schönen Abschluss hat. Und ich würde keinen Distributions-Maintainern glauben, die glauben kompetenter als die eigentlicher Software-Maintainer zu sein ;): “The latest stable Git release is v1.7.1.” (http://git-scm.com/). Ich schon. Die distributions-maintainer sehen nämlich ein viel breiteres Bild als die Software-Entwickler. Sie testen gegen die verschiedensten setups und binden oft noch patches ein, um alles zum Laufen zu kriegen. Dann hat Dir die neue Version doch etwas gebracht, #Friede_Freude_Eierkuche :). Sie wird mir was bringen, wenn sie stable wird :) (am Anfang war die wohl noch /richtig/ mies im Vergleich zu Mercurial), Auch ohne den Vergleich, ja :) wobei ich niemanden empfehlen würde, Git oder auch Mercurial ausſchließlich über die Manpages zu lernen. Dafür gibt es einfach viel zu viele, und man kann sich ja wohl kaum alphabetisch durchlesen … besser ist es da, mit einem guten Tutorial anzufangen. Stimmt. Warum haben wir eigentlich kein `tut git` und `tut hg` als Erweiterung zu `man git` und `man hg`? Ein standard tutorial-viewer wäre toll!
Re: [Neo] Git und Mercurial
Dennis Heidsiek wrote: Und ich würde keinen Distributions-Maintainern glauben, die glauben kompetenter als die eigentlicher Software-Maintainer zu sein ;): “The latest stable Git release is v1.7.1.” (http://git-scm.com/). $ ls /usr/portage/dev-vcs/git/files/*patch /usr/portage/dev-vcs/git/files/git-1.6.6-always-install-js.patch /usr/portage/dev-vcs/git/files/git-1.7.1-always-install-js.patch /usr/portage/dev-vcs/git/files/git-1.7.0-always-install-js.patch $ cat /usr/portage/dev-vcs/git/files/git-1.7.1-*.patch | head -n 4 JS install cleanup fixes - Also ensure the minified JS is built before instaweb as it is referenced in the sed expression. Liebe Grüße, Arne
Re: [Neo] [ticket] #209: Flyer passt nicht zur Referenz
#209: Flyer passt nicht zur Referenz ---+ Reporter: anonymous | Owner: Type: Verbesserung | Status: closed Priority: niedrig | Milestone: Neo Version 2.0 Component: Dokumentation/Wiki/Webseiten | Version: 2.0 BETA Resolution: fixed |Keywords: flyer Promotion ---+ Changes (by dennis): * status: new = closed * resolution: = fixed Comment: Inzwischen hat sich [source:grafik/promotion-material/Flyer in diesem Verzeichnis einiges getan], der mit Scribus erstellte Flyer ist durch eine bessere (und aktuellere) mit LaTeX erstellte Version ersetzt worden: Unter anderem gibt es jetzt sowohl [export:grafik/promotion- material/Flyer/Flyer.pdf eine farbige] als auch [export:grafik/promotion- material/Flyer/Flyer_sw.pdf eine rein schwarz-weiße] Version. Deshalb werde ich dieses Ticket jetzt erstmal schließen, wenn es noch weitere Probleme/Verbesserungsvorschläge für den Flyer gibt, einfach wieder hier melden! -- Ticket URL: https://wiki.neo-layout.org/ticket/209#comment:2 Neo-Layout http://neo-layout.org/ Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen direkt verfügbar macht.
Re: [Neo] [ticket] #209: Flyer passt nicht zur Referenz
#209: Flyer passt nicht zur Referenz ---+ Reporter: anonymous | Owner: Type: Verbesserung | Status: closed Priority: niedrig | Milestone: Neo Version 2.0 Component: Dokumentation/Wiki/Webseiten | Version: 2.0 BETA Resolution: fixed |Keywords: flyer Promotion ---+ Comment(by anonymous): Danke vielmals, so ists gut. Ich drucke gleich mal 100. Danke. -- Ticket URL: http://wiki.neo-layout.org/ticket/209#comment:3 Neo-Layout http://neo-layout.org/ Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen direkt verfügbar macht.
Re: [Neo] Individualisierte Layouts als Vision?
Huhu! In Zusammenhang mit der Frage, ob Ulfs Strafpunkteverteilung von/für NordTast sinnvoll ist, ist mir da auch folgende Idee gekommen: Wie wäre es mit einer netten grafischen Oberfläche und/oder einer Konfigurationsdatei wo man Strafpunkte für die verschiedenen Tasten, Handwechsel usw. setzen kann und anschließend das optimale individuelle Layout erstellt wird? In Kombination mit einer einfachen Anpassbarkeit des generierten Layouts und/oder der Auswahl verschiedener höherer Ebenen (so mancher mag vielleicht auf Ebene 5 und 6 die Buchstaben der Lautschrift, Blindenschrift, Klingonisch, Elbisch etc. statt Griechisch) wäre das eine geniale Sache. In Hinblick auf beträchtliche Unterschiede bei Anatomie, verwendeter Tastatur, Einsatzgebiet uvm. wäre eine solche Lösung wünschenswert. Die zierliche Frau mit den kleinen Händen die auf einer großen Tastatur mit schwer zu betätigenden Tasten ihre wissenschaftlichen Artikel tippt wird ein deutlich anderes Layout wünschen als der Mann mit den breiten Schultern der sich mit den winzigen Tasten eines kleinen Netbooks quält, öfters Englisch schreibt und außerdem vi verwendet. Liebe Grüße und schönes Wochenende! Michael
Re: [Neo] Gedanken zu Programm zum Konvertieren von Text zum praktischen Testen von neuen Layouts?
Hi Arne, Kann man davon ausgehen, dass, wer bereit ist, sich auf eine Tastenbelegung mit 10 veränderten Qwertz-Tasten (5 Tastenpaare) einzulassen, besser gleich auf eine komplett neue Belegung umsteigt? Denke ich, ja. Deswegen habe ich hier auch mal die Einzel- und Doppelvertauschung gepostet. Drei wäre übrigens das hier: qwört zundpü asofg hjkleä yxcvb im,.- # 3.82015149667 billion total penalty compared to notime-noeffort Apropos penalty-Werten. In einer Auswertung vor ein paar Wochen (Neo, Nordtast und andere) bewegten sich die Zahlen auf einem ganz anderen Niveau. Waren dort so unterschiedliche Kosten vergeben? Fazit: Mit den Vertauschungen lässt sich zwar viel erreichen, aber ein optimales Layout sieht anders aus. Absolute Zustimmung, aber _wenn_ der Aufwand sehr überschaubar bleibt und man schon viel erreicht, so denke ich, dass so ein Layout den einen oder anderen (mich zum Beispiel ;-)) überhaupt motivieren könnte, den Versuch mit einem neuen Layout zu wagen :-) Die Gewichtung der einzelnen Kosten ist dabei allerdings der absolute Knackpunkt, da hier z.B. v.a. die Zeilenwechsel minimiert wurden. Die Gewichtung ist der _einzige_ Knackpunkt für die Berechnung :-o Ich glaub' wir haben ein wenig aneinander vorbei geredet :-o Meine Grundidee, die ich ausdrücken wollte war: Experimente überlegen / durchführen, die eine gute Basis zur Erstellung einer guten Kostenstruktur (Penalty-Punkten) beitragen. Jetzt schaue ich und sehe, dass mit den derzeitigen Gewichtungen als zweiter Tausch das Optimierungs-Skript d gegen o tauscht. Meinst Du, dass das tatsächlich der zweitwichtigste / effektivste Tausch ist Das Skript prüft gegen sehr viel mehr Parameter als nur „wer ist am häufigsten“ und „wie gut ist die Einzeltaste zu erreichen“. Das ist mir klar. Genau das ist ja der Vorteil von einem Skript, aber zurück zur Frage. Denkst Du, dass das tatsächlich (ein möglicher) zweitwichtigster Tausch wäre und noch z. B. vor einem n-j-Tausch (nur als Beispiel) stehen sollte? Ich denke, dass man bei einer so überschaubaren Layoutänderung mit guter Überlegung, ggf. ein paar _unterstützenden_ Berechnungen in Bezug auf Bi- und Trigramme, Fingerwechsel usw. und nicht zuletzt eines kurzen Praxistests recht gut das bzw. eines der effektivsten Mini-Änderungen ergründen könnte. Wenn dies erreicht wird, dann kann man dieses gute Layout nutzen, um dagegen die reinen berechneten Kostenstrukturen zu prüfen und kann so schon mal Ungereimtheiten in den Kostenstrukturen entdecken. Ungereimtheit meint hier eine Nichtübereinstimmung von berechnetem Erfolg und dem gefühlten Erfolg. Daher: Nach den aktuellen Parametern ist das die beste Vertauschung, ja. Klar :-) Ich meine aber nicht nach den Parametern / Kosten im Moment, sondern mein Gedanke ist, ob es nicht möglich sein sollte bei sehr überschaubaren Änderungen mit einigen Tipptests systematisch herauszubekommen, welche Änderung mehr bringt _und_ dann die Kosten so zu optimieren, dass dieses Ergebnis (zumindest angenähert) auch über die Optimierung erreicht wird. Trotzdem würde es mich wundern, wenn das häufig genutzte n auf der nicht sooo dollen Position (gut, sooo schlecht ist sie auch nicht) bleiben wird und nicht ziemlich schnell in die Grundreihe rutscht? Vor allem muss auch das j aus der Grundreihe verschwinden. Bei den 5 wichtigsten / effektivsten Tauschpaaren, bin ich mir sehr sicher, dass das dabei sein muss und auch recht bald in einer Optimierungsreihenfolge auf der Grundreihe Platz machen muss. Meinst Du das auch? Ich Maße mir nicht an, alle Bigramme und Trigramme der deutschen Sprache im Kopf zu haben. Ich hoffe wir reden nicht aneinander vorbei. Natürlich hat man nicht die ganzen Bigramme und Trigramme und möglichen Wechselwirkungen im Kopf :-) Ich hab' erstmal nur einen Blick auf die 1-Gramme geworfen und dann ein kleines Tauschlayout gebastelt. Beim Testtippen merkte ich schnell, dass das nicht eine gute Lösung ist, da dann Fingerwiederholungen usw. hässlich werden können. Das ist genau dein Punkt, dass man mit einfacher Überlegung _allein_ auch nicht schnell so weit kommt. Genau deswegen habe ich den Optimierer geschrieben (sonst hätte ich auch gleich von Hand designen können). Ja, meine Überlegung zielt darauf ab, wie man die besten gefühlten Kombinationen findet und diese dann in passende Kosten umwandeln kann! 1) Wie findet man eine gute Kostenverteilung? Das ist genau die wichtigste Frage. Sie fragt nämlich direkt: Was ist gutes Tippen. Das ist die grundlegende Vorbedingung um irgendwelche Kosten festzulegen. Wenn man zustimmt, dass ein Text am bequemsten zu tippen wäre, wenn man nur die 8 Finger in der Grundstellung bewegen müsste, so sollten die ersten 8 1-Gramme in der Grundstellung landen. Dem Programm könnte ich also schon vorschreiben, dass die Variation dieser Buchstaben nur noch in der Grundreihe zu erfolgen hat! Wenn du das willst, nimm’ Neo 2. Das macht genau das. Ich weiß, sehe
Re: [Neo] Gedanken zu quot;Programm zum Konvertieren v on Text zum praktischen Testen von neuen Layouts?quot;
Hallo Karl, Für ein neues 5er-Layout könnte man 5 bis 7 mögliche gute und 5 bis 7 mögliche schlechte Zeichen suchen, die sich bewegen müssen Wenn ich es zutreffend auffasse, geht es hierbei um das Vertauschen der Belegung von Tastenpositonenpaaren bezogen auf die Qwertz-Belegung. Genau. 5 Tastenpaare zu tauschen (bedeutet 10 anders belegte Tasten), das erscheint mir schlichtweg zu viel, um die Grundidee sinnvoll umzusetzen, nur wenige Tastenbelegungen zu vertauschen. Ich schätze das ähnlich ein, wenn es darum geht, dass man zum neuen Layout auf einmal umsteigen will ... Kann man davon ausgehen, dass, wer bereit ist, sich auf eine Tastenbelegung mit 10 veränderten Qwertz-Tasten (5 Tastenpaare) einzulassen, besser gleich auf eine komplett neue Belegung umsteigt? ... und so dürfte es tatsächlich eher interessanter sein, dann gleich ein komplett neues Layout zu lernen. Interessant wird der Gedanke mit nur 4 oder 5 (gz evtl. noch 6) vertauschten Paaren aber, wenn man a) mit nur 10 neuen Plätzen eine sehr deutliche Verbesserung zum vorigen Layout gewinnt, die schon relativ nahe im Vergleich an einem optimalen Layout ist und b) wenn man annimmt / feststellt, dass ein stückweiser Umstieg auf ein neues Layout mit jeweils nur einem Tastentausch einen relativ glatten Übergang ermöglicht, bei dem man nicht beinahe komplett von 100 auf 0 ausgebremst wird. Ich kann mir zur Zeit (und vermute dass sich das nicht so schnell ändert), nicht erlauben für einige Wochen _sehr_ uneffektiv tippen zu müssen. Daher reizt es mich die Idee zu testen. Viele Grüße Peter
[Neo] [ticket] #218: windows 7
#218: windows 7 ---+ Reporter: anonymous | Owner: Type: Fehler/Defekt | Status: new Priority: normal | Milestone: Neo Version 2.0 Component: Treiber: Windows – Kbdneo | Version: 2.0 Final Keywords: | ---+ der treiber erzeugt bei mir ein leeres layout und läst sich nicht anwenden- steht aber in der liste. grade durch die touchscreen unterstützung von W7 würde ich mir ein funktionierenden treiber für w7 wünschen -- Ticket URL: http://wiki.neo-layout.org/ticket/218 Neo-Layout http://neo-layout.org/ Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen direkt verfügbar macht.