Re: [Neo] script: ref2svg
Am 06.04.2010 15:00, schrieb Martin Roppelt: Persönlich finde ich zudem UTF-8 leichter zu lesen (und so zu editieren) als keysyms. Sehe ich auch so, außerdem gibt es nicht für jeden Unicode ein Keysym, das wäre also immer nen Mischmasch. Unicode für Unicodezeichen, Namen für Funktionen (Pos1, Ende, usw…) ist schön eindeutig :D Gruß Florian signature.asc Description: OpenPGP digital signature
Re: [Neo] script: ref2svg
Hallo allerseits, Florian Janßen ſchrieb am 07.04.2010 21:55 Uhr: Das sehe ich genau anders. […] Diese Darstellung hat auch den Vorteil, dass sie selbst mit US-ASCII lesbar ist und die Darstellung nicht von der Schriftart abhängt (selbst deja vu fehlt immernoch das ẞ!). Hm, dieses Argument kann ich nachvollziehen, aber ein guter Editor sollte durchaus fähig sein, fehlende Glyphen aus anderen Schriften zu ›zwiebelfischen‹. Die für Menschen lesbare kann daraus erzeugt werden, birgt aber Fehlerquellen. Diese ganzen lange von Dir vorgeschlagenen Hex-Repräsentationen von Unicode-Codepunkten bergen auch Fehlerquellen, wenn man die bearbeitet … bei so vielen Zahlen kann man sich ja leicht mal vertun, und da sieht man halt auch nicht, was man eigentlich editiert. So lässt sich dein Beispiel „♫poi=⌘ # point of interest“ kaum von „♫pοi= kein Eintrag“ unterscheiden. Nein, das sehe ich nicht so. Gerade durch die kompakte Darstellung fallen einem die beiden fehlenden Zeichen in der zweiten Zeile besonders ins Auge. Verwechlungen sind hier vorprogrammiert, so wie letztens die Verwechslung von Bullet und Bullet Operator (den es IIRC nur auf meinem Keyboard gibt). Stimmt, optisch gleich ausſehnde Zeichen sind nicht so schön, hier könnte man aber durch Keysyms Abhilfe schaffen. Mit Deiner Darstellung könnte ich durchaus auch leben, aber da müsste man erst ein eigenes Programm schreiben, mit dem man dieses Format bequem editieren kann. Wenn wir die ›Datenbank‹ in einer tieferen Abstraktionsebene ›verstecken‹, kann uns ihr Format eigentlich vollkommen egal sein – aber ich würde es doch vorziehen, wenn ich sie direkt (und bequem) ansehen, verstehen und bearbeiten könnte. Pascal Hauck ſchrieb am 07.04.2010 22:49 Uhr: Am Mittwoch, 7. April 2010 21:55:29 schrieb Florian Janßen: 156 (C|4) (U1234, U5678, U9098,pos1, k|U7654, U3212) […] Der erste Schritt wäre zwangsläufig ein Skript, das daraus eine lesbare Form macht, um die vorgenommenen Änderungen zu überprüfen. Dann aber hat Martin Recht und wir können das Skript auch anders herum schreiben und aus den Zeichen die Unicodes oder Keysyms basteln. Finde ich auch. Aber was meinen die anderen Programm-Entwickler (wie Arne)? Viele Grüße, Dennis-ſ
Re: [Neo] script: ref2svg
Am Dienstag, den 06.04.2010, 16:57 +0200 schrieb Pascal Hauck: Hatte Franks Mail nicht gelesen. Da ist sie noch einmal: http://lists.neo-layout.org/pipermail/diskussion/2010-February/015722.html Sorry, ich weiß leider nicht, wie ich die „E-Mail-ID“ herausfinden kann. Am Dienstag, 6. April 2010 16:42:58 schrieb Martin Roppelt: Sowas kann man doch unterscheiden (war auch schon in Franks E-Mail beschrieben: * für *, und k* für KP_Multiply, - für Bindestrich-Minus, s- für SHY, usw.) Im Prinzip also doch eigene Keysyms. Fraglich, ob eine weitere Definitionschicht (eigene Keysyms) die Lage tatsächlich vereinfacht, aber wenn ihr glaubt, dass es dadurch einfacher wird, soll mich das nicht stören. Das war nur provisorisch. Meine Grundidee war, eine Referenzdatei zu haben, die auf möglichst viele Redundanzen verzichtet und möglichst kurze Zeichen/Wörter hat. Also statt dead_gravis oder so einfach nur d`. Und eben auch solche Konstruktionen wie k* statt K_Multip… (Dass a und A hintereinander stehen, finde ich schon fast Redundanz zu viel, aber so ist es technisch am einfachsten gewesen.) Dies bedeutet im Übrigen auch der Verzicht der Caps-Lock-Eigenschaft in der Datei layout. tschau Frank
Re: [Neo] script: ref2svg
Am 07.04.2010 16:40, schrieb Dennis Heidsiek: Frank Stähr ſchrieb am 07.04.2010 12:19 Uhr: Also statt dead_gravis oder so einfach nur d`. d` oder d̀ ? Was ist mit unsichtbaren Zeichen? ;) Wir werden für die verschiedenen Treiber/Grafiken/Plaintextdarstellungen eh’ in verschiedene Formate konvertieren müssen, also sollte man sich bei der abstrakten Referenz ruhig für die ›schönste‹ – sprich für einen Menschen am besten lesbare – Variante entscheiden. Das sehe ich genau anders. Gerade bei der Referenz sollten wir bei der eindeutigsten Lösung bleiben. Ich fände eine Darstellung wie Scancode (Capslockflag,Mod4Lockflag)(E₁,E₂,E₃ …) gut, mit Eₓ als Unicode wenn Zeichen und passenden keysym wenn Funktion, da eindeutig, gerne als »d« (dead) oder »k« (Numpad) geflaggt. Eine Zeile könnte dann z.B. so aussehen: 156 (C|4) (U1234, U5678, U9098, pos1, k|U7654, U3212) Für mich(!) liest sich das auch viel besser, als die ewig lange Schreibweise mit den Unicode-Namen, bzw. den Keysyms. Keysyms gibt es außerdem auch nicht für alle Unicodes und man hat dann doch wieder einen Mischmasch. Diese Darstellung hat auch den Vorteil, dass sie selbst mit US-ASCII lesbar ist und die Darstellung nicht von der Schriftart abhängt (selbst deja vu fehlt immernoch das ẞ!). Die für Menschen lesbare kann daraus erzeugt werden, birgt aber Fehlerquellen. So lässt sich dein Beispiel „♫poi=⌘ # point of interest“ kaum von „♫pοi= kein Eintrag“ unterscheiden. Verwechlungen sind hier vorprogrammiert, so wie letztens die Verwechslung von Bullet und Bullet Operator (den es IIRC nur auf meinem Keyboard gibt). Gruß Florian signature.asc Description: OpenPGP digital signature
Re: [Neo] script: ref2svg
Am Mittwoch, 7. April 2010 21:55:29 schrieb Florian Janßen: 156 (C|4) (U1234, U5678, U9098, pos1, k|U7654, U3212) Der Grund, warum es für Linux überhaupt Keysyms gib, ist der, dass exakt solche unleserlichen und obendrein fehleranfälligen Konstrukte vermieden werden sollen. Der erste Schritt wäre zwangsläufig ein Skript, das daraus eine lesbare Form macht, um die vorgenommenen Änderungen zu überprüfen. Dann aber hat Martin Recht und wir können das Skript auch anders herum schreiben und aus den Zeichen die Unicodes oder Keysyms basteln. Gruß, Pascal signature.asc Description: This is a digitally signed message part.
Re: [Neo] script: ref2svg
Am Montag, den 05.04.2010, 17:36 +0200 schrieb Knittl: 2010/4/5 Frank Stähr !^*?|$...@gmx.net: […] wenn ich dich richtig verstanden habe, solltest du wohl meine Mails noch einmal lesen. Wohl auch die vom Februar. weder du, ich oder sonstjemand, der neo tippt will einem anderen neoling was böses – also lieber frank, lies auch bitte meine mails ordentlich ;) Du hast da was aus dem Zusammenhang gerissen, nämlich vielleicht hast du dich ja bei deinem »Eine Datei z. B. svg enthlt die Keycodes« auch nur vertippt, auf das wollte ich auch hinweisen. und außerdem hast du meine Mailaddy hier im Klartext geschickt – ich bin also einfach davon ausgegangen, dass du von Grund auf böse bist ;-) Nein, ernsthaft, meiner Adresse macht das nichts mehr aus und meine Implementierung erkläre ich noch einmal möglichst unmissverständlich und diesmal vollständig: Meine Lösung bestand im Wesentlichen aus *drei* Dateien, nämlich layout, systemcodes und dem awk-Skript. Die Datei layout sieht etwa so aus: lnxkcd10 1 ° ¹ ª ₁ ¬ lnxkcd11 2 § ² º ₂ ∨ lnxkcd12 3 ℓ ³ № ₃ ∧ lnxkcd13 4 » › ⇞ ♀ ⊥ usw. Das erste in jeder Zeile ist das, was ich Keycode nenne. Es bezeichnet eine Taste auf der Tastatur und ist unabhängig vom Layout. Dahinter kommen die sechs Zeichen der sechs Ebenen, die zu der jeweiligen Taste gehören (hier also ein Teil der Zahlenreihe). systemcodes: utf8neo_de.xmodmap 1 1 ° degree ¹ onesuperior ª ordfeminine ₁ onesubscript ¬ notsign 2 2 § section ² twosuperior º masculine Die erste Zeile enthält die „Kategorien“, zu denen die in den Spalten stehenden Wörter bzw. Zeichen gehören, also UTF-8, neo_de.xmodmap, ahk, xkb usw. (Spalten und Zeilen auch hier nur auszugsweise). Die dritte Datei ist das awk-Skript, damit erhält man: Eine Datei – **z. B.** irgendeine svg-Datei (ich hatte als Beispiel die neo_de.xmodmap) – enthält die /Keycodes/, also nicht das Layout. awk läuft da durch und ersetzt diese automatisch mit den tatsächlichen Zeichen. Damit hat man also /ein/ Programm für /alle/ layoutabhängigen Dateien, ob nun neo_de.xmodmap, ahk oder eben auch svg. alles was ich gesagt hab, ist, dass svg nicht die beste basis darstellt – das hast du in deinem mail so geschrieben. Ja, als Zitat für sich alleine war das tatsächlich nicht so klar. Aber nun wissen wir, dass das Layout also nicht in der svg, sondern in der Datei layout gespeichert ist. und den scancode (…, …) vorschlag hab ich gelesen, deshalb auch meine anmerkung, dass gewisse treiber informationen brauchen, die so eben nicht darstellbar sind und jeder treiber die zu erzeugenden zeichen und deren zugehörigen in einem anderen format benötigt. Genau, und dafür ist die Datei systemcodes. Dies alles ist recht simpel; das Problem, das bleibt, ist die Bearbeitung aller layoutabhängigen Dateien, und das sind zur Zeit praktisch alle. Man muss also überall in diesen Dateien ° (bzw. degree) durch lnxkcd10_2 ersetzen usw. (hier: Linux Keycode № 10, Ebene 2). Davon abgesehen finde ich Martins Vorschlag gut, aus so einer Datei layout noch eine besser menschenlesbare Datei zu erzeugen. In dieser müssen ja auch die Positionen und das Verhalten der Modifier beschrieben werden. (Eine besser technisch lesbare Referenz ist mit dieser Implementierung erstmal nicht unbedingt nötig.) tschau Frank
Re: [Neo] script: ref2svg
On 06.04.2010 12:47, Frank Stähr wrote: Die Datei layout sieht etwa so aus: lnxkcd10 1 ° ¹ ª ₁ ¬ lnxkcd11 2 § ² º ₂ ∨ lnxkcd12 3 ℓ ³ № ₃ ∧ lnxkcd13 4 » › ⇞ ♀ ⊥ usw. Nur zur Info: Man sollte auch für jede Taste definieren, wie sie sich im Caps-Modus verhält. Buchstaben haben dann die Ebenen 1 und 2 getauscht, Ziffern und Satzzeichen aber nicht. – Mœsi
Re: [Neo] script: ref2svg
Am Dienstag, 6. April 2010 12:47:35 schrieb Frank Stähr: Die Datei layout sieht etwa so aus: lnxkcd10 1 ° ¹ ª ₁ ¬ Während Keysym→Unicode→Zeichen eindeutig ist, gilt die Umkehrung nicht! Aus diesem Grund ist die bloße Angabe des zu erzeugenden Zeichens oder dessen Unicode unzureichend! Als Folge würden verschiedene Treiber ein abweichendes Verhalten zeigen, außerdem würden viele Cokos nicht funktionieren. Darum muss eine allgemeingültige Referenz zwingend Keysyms beinhalten, z.B. angelehnt an die Struktur der Xmodmap: keycode 38 = u U backslash NoSymbol Home Home includedin NoSymbol Problemlos könnte via Makefile daraus eine nachgeordnete Referenz mit Unicodes statt Keysyms erstellt werden. Gruß, Pascal signature.asc Description: This is a digitally signed message part.
Re: [Neo] script: ref2svg
Hallo Pascal, Pascal Hauck schrieb: Am Dienstag, 6. April 2010 12:47:35 schrieb Frank Stähr: Die Datei layout sieht etwa so aus: lnxkcd10 1 ° ¹ ª ₁ ¬ Während Keysym→Unicode→Zeichen eindeutig ist, gilt die Umkehrung nicht! Aus diesem Grund ist die bloße Angabe des zu erzeugenden Zeichens oder dessen Unicode unzureichend! Als Folge würden verschiedene Treiber ein abweichendes Verhalten zeigen, außerdem würden viele Cokos nicht funktionieren. Darum muss eine allgemeingültige Referenz zwingend Keysyms beinhalten, z.B. angelehnt an die Struktur der Xmodmap: keycode 38 = u U backslash NoSymbol Home Home includedin NoSymbol Hä? In einer zweiten Datei würde man schreiben, wie die Glyphen zu den keysyms zugeordnet würden. Oder gäbe es Doppeldeutigkeiten (von Normalisierung mal abgesehen)?? Mach doch bitte mal ein Beispiel. Einen Konflikt könnte ich mir höchstens noch bei »Bewegungstasten« vorstellen, aber die sind ja auch eindeutig, da die Symbolisierungen nicht auf der Tastatur vorhanden sind. Zumal würden sie eh durch einen eigenen zweibuchstabigen Keysym symbolisiert, wie auch Keypad-Varianten. Persönlich finde ich zudem UTF-8 leichter zu lesen (und so zu editieren) als keysyms. Gruß, Martin
Re: [Neo] script: ref2svg
Pascal Hauck schrieb: Am Dienstag, 6. April 2010 15:00:12 schrieb Martin Roppelt: Hä? […] Mach doch bitte mal ein Beispiel. Einerseits gibt es Unterschiede zwischen KP_- und Nicht‑KP_-Varianten (z.B. KP_1, KP_Substract oder KP_Left), andererseits werden Fragen wie μ oder µ durch das bloße Bild nicht aufgedeckt. Drittens gibt es bei manchen Keysyms Probleme, die entweder falsch (uptack statt downtack) oder gar nicht definiert sind (dead_stroke, dead_psili, …) Komisch, ich dachte, ich hätte mich weiter unten deutlich genug ausgedrückt… Sowas kann man doch unterscheiden (war auch schon in Franks E-Mail beschrieben: * für *, und k* für KP_Multiply, - für Bindestrich-Minus, s- für SHY, usw.) Im Prinzip also doch eigene Keysyms. So immer noch gut zu lesen und ohne Missverständnisse (die Linux-Keysyms würde ich übrigens an dieser Stelle wirklich ungerne sehen, denn die kann sich doch wirklich keiner merken …)
Re: [Neo] script: ref2svg
Am Dienstag, 6. April 2010 16:42:58 schrieb Martin Roppelt: Sowas kann man doch unterscheiden (war auch schon in Franks E-Mail beschrieben: * für *, und k* für KP_Multiply, - für Bindestrich-Minus, s- für SHY, usw.) Im Prinzip also doch eigene Keysyms. Hatte Franks Mail nicht gelesen. Fraglich, ob eine weitere Definitionschicht (eigene Keysyms) die Lage tatsächlich vereinfacht, aber wenn ihr glaubt, dass es dadurch einfacher wird, soll mich das nicht stören. Gruß, Pascal signature.asc Description: This is a digitally signed message part.
Re: [Neo] script: ref2svg
das meiste hat ja schon dennis in einem anderen mail beantwortet, deshalb antworte ich jetzt nur auf die fragen, die direkt mein script betreffen. 2010/4/4 Frank Stähr der-storch...@gmx.net: aber passend zum osterwochenende hab ich jetzt endlich mal an einem skript gebastelt, welches eine svg-grafik von neo aus der referenz erzeugt. Dann ging’s noch weiter: Eine Datei – z. B. svg – enthält die Keycodes und ein Programm ersetzt diese automatisch mit den tatsächlichen Zeichen. Damit hat man also /ein/ Programm für /alle/ layoutabhängigen Dateien, ob nun neo_de.xmodmap, ahk oder eben auch svg. find ich nicht gut, wenn svg die basis darstellt. dann lieber ein leicht parsbares textfile, csv, xml, json oder yaml. das eine einzige programm für alle treiberdateien, oder unterschiedlichen darstellungen wird nicht ganz so einfach. jeder treiber benötigt andere informationen (xkb: x-keycodes, xmodmap: das ursprüngliche zeichen, ahk: das ursprüngliche zeichen als scancode (?)) wie dennis in dem anderen mail bereits erwähnt hat, die idee gab's schon des öfteren, bis jetzt ist es aber an der umsetzung gescheitert – mein script ist primär für die erzeugung von schönen tastaturaufklebern gedacht, kann aber ruhig als erster schritt in die richtung betrachtet werden. Habe mir dein Skript nicht genau angeschaut (kann kein Perl), aber dieses ist doch sicherlich an die eine svg-Datei gebunden, oder? ich kann auch kein perl, war mein erstes (sinnvolles) skript in perl *g* und ney, das script ist standalone hängt also nur von perl und dem `XML::Writer`-modul ab (und wenn man es drauf anlegt, könnte man alles auf eine riesenmenge von print-statements umarbeiten …) richtig sauber hätte natürlich alles in eine klasse gebastelt gehört, welche ein interface implementiert, die implementierende klasse kann dann ausgetauscht werden um verschiedene darstellungen/treibertypen zu erzeugen. oder aber, es gibt seperate skripte, die alle auf den parser zugreifen, da dürfen sich softwarearchitekten dann streiten, welche die sinnvollere lösung für dieses problem ist :D folgende funktionien sind im moment vorhanden und können von interessierten jetzt schon auf andere darstellungen portiert werden (die namen dann eventuell von _svg befreien …): • `start_svg`: der prolog, für alle dateien gleich (doctype und `svg`-element für svg) • `end_svg`: der epilog, hier für svn einfach nur der schließende `svg`-tag • `create_defs`: ein weiterer prolog, hier werden globale definition generiert (stylesheet-informationen, rahmen für die tasten) • `create_keys`: ruft `create_key` auf • `parse_ref`: der kern des parsers, fischt sich aus neo20.txt ein zweidimensionales array mit den tasten heraus – wenn auch ein hässliches, weil nach ebenen und nicht nach tasten gruppiert, aber es hat funktioniert • `create_keys`: erzeugt eine einzelne taste, kümmert sich auch um die positionierung im svg, teile davon sollten `create_keys` verschoben werden lg, daniel -- typed with http://neo-layout.org myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
Re: [Neo] script: ref2svg
Am Montag, den 05.04.2010, 08:49 +0200 schrieb Knittl: 2010/4/4 Frank Sthr !^*?|$...@gmx.net: Dann gings noch weiter: Eine Datei z. B. svg enthlt die Keycodes und ein Programm ersetzt diese automatisch mit den tatschlichen Zeichen. Damit hat man also /ein/ Programm fr /alle/ layoutabhngigen Dateien, ob nun neo_de.xmodmap, ahk oder eben auch svg. find ich nicht gut, wenn svg die basis darstellt. dann lieber ein leicht parsbares textfile, csv, xml, json oder yaml. das eine einzige programm fr alle treiberdateien, oder unterschiedlichen darstellungen wird nicht ganz so einfach. jeder treiber bentigt andere informationen (xkb: x-keycodes, xmodmap: das ursprngliche zeichen, ahk: das ursprngliche zeichen als scancode (?)) Lieber Knittl, nach wie vor danken wir dir für deinen Einsatz, aber wenn ich dich richtig verstanden habe, solltest du wohl meine Mails noch einmal lesen. Wohl auch die vom Februar. Ich habe gerade gesehen, dass Florian gestern schon einen Vorschlag nannte, der meinem sehr ähnlich kommt. (Scancode (E₁,E₂,E₃,E₄,E₅,E₆) usw.) Gruß Frank
Re: [Neo] script: ref2svg
2010/4/5 Frank Stähr der-storch...@gmx.net: Am Montag, den 05.04.2010, 08:49 +0200 schrieb Knittl: 2010/4/4 Frank Sthr !^*?|$...@gmx.net: Dann gings noch weiter: Eine Datei z. B. svg enthlt die Keycodes und ein Programm ersetzt diese automatisch mit den tatschlichen Zeichen. Damit hat man also /ein/ Programm fr /alle/ layoutabhngigen Dateien, ob nun neo_de.xmodmap, ahk oder eben auch svg. find ich nicht gut, wenn svg die basis darstellt. dann lieber ein leicht parsbares textfile, csv, xml, json oder yaml. das eine einzige programm fr alle treiberdateien, oder unterschiedlichen darstellungen wird nicht ganz so einfach. jeder treiber bentigt andere informationen (xkb: x-keycodes, xmodmap: das ursprngliche zeichen, ahk: das ursprngliche zeichen als scancode (?)) Lieber Knittl, nach wie vor danken wir dir für deinen Einsatz, aber wenn ich dich richtig verstanden habe, solltest du wohl meine Mails noch einmal lesen. Wohl auch die vom Februar. Ich habe gerade gesehen, dass Florian gestern schon einen Vorschlag nannte, der meinem sehr ähnlich kommt. (Scancode (E₁,E₂,E₃,E₄,E₅,E₆) usw.) alles was ich gesagt hab, ist, dass svg nicht die beste basis darstellt – das hast du in deinem mail so geschrieben. und den scancode (…, …) vorschlag hab ich gelesen, deshalb auch meine anmerkung, dass gewisse treiber informationen brauchen, die so eben nicht darstellbar sind und jeder treiber die zu erzeugenden zeichen und deren zugehörigen in einem anderen format benötigt. oft werden auf dieser mailingliste sachen doppelt diskutiert oder doppelt erwähnt, das ist per se nichts schlechtes. vielleicht hast du dich ja bei deinem »Eine Datei z. B. svg enthlt die Keycodes« auch nur vertippt, auf das wollte ich auch hinweisen. weder du, ich oder sonstjemand, der neo tippt will einem anderen neoling was böses – also lieber frank, lies auch bitte meine mails ordentlich ;) -- typed with http://neo-layout.org myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
Re: [Neo] script: ref2svg
Am Samstag, den 03.04.2010, 12:49 +0200 schrieb Knittl: ps. wir sollten uns echt ein format fr die referenz berlegen, welches einfacher zu parsen ist Knittl, bitte verstehe das nicht falsch, aber mal ganz fernab von dieser Arbeit: In meiner Mail vom 10. Feb. 22:18 Uhr habe ich mich doch auch schon mit dieser Problematik befasst. Meine Lösung war eine Datei „layout“, die etwa so aussieht: lnxkcd10 1 ° ¹ ª ₁ ¬ lnxkcd11 2 § ² º ₂ ∨ lnxkcd12 3 ℓ ³ № ₃ ∧ lnxkcd13 4 » › ⇞ ♀ ⊥ usw. Das erste ist ein layoutunabhängiger Keycode, dahinter kommen die sechs Zeichen der sechs Ebenen (hier also ein Teil der Zahlenreihe). In jedem Fall braucht man aber eine Referenz, die nicht allgemein parse-bar ist. Egal, was man sich ausdenkt, man findet immer irgendetwas an der Referenz, dass man doch in menschlichen Worten beschreiben muss (gewisse Tastenkombis etc.). jetzt wo neo (2) fertig ist, machts natrlich nicht mehr ganz so viel sinn Doch, doch, für die Zukunft schon wertvoll. aber passend zum osterwochenende hab ich jetzt endlich mal an einem skript gebastelt, welches eine svg-grafik von neo aus der referenz erzeugt. Dann ging’s noch weiter: Eine Datei – z. B. svg – enthält die Keycodes und ein Programm ersetzt diese automatisch mit den tatsächlichen Zeichen. Damit hat man also /ein/ Programm für /alle/ layoutabhängigen Dateien, ob nun neo_de.xmodmap, ahk oder eben auch svg. Habe mir dein Skript nicht genau angeschaut (kann kein Perl), aber dieses ist doch sicherlich an die eine svg-Datei gebunden, oder? Die Frage, die sich mir nun stellt, ist: War meine Idee bzw. die zugehörige Umsetzung einfach nicht gut oder ist sie hier auf der ML total untergegangen? Beides würde ich nicht sonderlich toll finden, in jedem Fall wäre aber meine Arbeit umsonst gewesen … tschau Frank
[Neo] script: ref2svg
hallo liebe neo-gemeinde, jetzt wo neo (2) fertig ist, machts natürlich nicht mehr ganz so viel sinn, aber passend zum osterwochenende hab ich jetzt endlich mal an einem skript gebastelt, welches eine svg-grafik von neo aus der referenz erzeugt. im moment werden die ersten vier ebenen angezeigt, wobei e1 auf dem hauptfeld fehlt, da ja sowieso die großbuchstaben sichtbar sind. die modifier und sonstige spezialtasten (tab, backspace, return) habe ich noch nicht vernünftig hingebracht, deshalb gibt's im moment nur normale tasten – was aber für den anfang reichen sollte ;) ich persönlich finde die generierte grafik jedenfalls ganz annehmbar (hab ja auch ich gemacht :D) die generierte grafik habe ich von den abmessungen an die tastatur von meinem notebook angepasst, sollte aber eigentlich auf die meisten tastaturen gut draufpassen. falls jemand wünsche, beschwerden oder anregungen hat, kann er sie entweder direkt im script umsetzen oder sich bei mir melden. das script findet sich im git^Wsvn unter /grafik/ref2svg/ schönes wochenende noch, daniel ps. wir sollten uns echt ein format für die referenz überlegen, welches einfacher zu parsen ist … -- typed with http://neo-layout.org myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
Re: [Neo] script: ref2svg
Knittl schrieb am 03.04.2010 12:49: hallo liebe neo-gemeinde, jetzt wo neo (2) fertig ist, machts natürlich nicht mehr ganz so viel sinn, aber passend zum osterwochenende hab ich jetzt endlich mal an einem skript gebastelt, welches eine svg-grafik von neo aus der referenz erzeugt. im moment werden die ersten vier ebenen angezeigt, wobei e1 auf dem hauptfeld fehlt, da ja sowieso die großbuchstaben sichtbar sind. die modifier und sonstige spezialtasten (tab, backspace, return) habe ich noch nicht vernünftig hingebracht, deshalb gibt's im moment nur normale tasten – was aber für den anfang reichen sollte ;) ich persönlich finde die generierte grafik jedenfalls ganz annehmbar (hab ja auch ich gemacht :D) Das Ergebnis sieht schon vielversprechend aus :-). Eine Frage an die, die mehr über den Server wissen: Ist Perl installiert? Wenn ja, könnte ja das Makefile für die Grafiken ergänzt werden. Mit freundlichen Grüßen Frakturfreak -- Wenns halt war, wies halt war, irgendwie wars, denn noch nie wars, dass es nicht irgendwie war. Mein Blog: http://frakturfreaks-kleine-dinge.1on.de/ signature.asc Description: OpenPGP digital signature
Re: [Neo] script: ref2svg
Hallo allerseits, Christian Kluge ſchrieb am 03.04.2010 18:15 Uhr: Eine Frage an die, die mehr über den Server wissen: Meines Wissens ist Ben die einzige Person, die wirklich Ahnung vom Server hat … Ist Perl installiert? Meines Wissens läuft auf dem Server ein älteres Ubuntu – ist da Perl in der Standardvariante mit dabei? Wenn ja, könnte ja das Makefile für die Grafiken ergänzt werden. Oder wir ergänzen erst das Makefile, sehen ob es klappt und wenn nicht: nette Rückfrage beim Master of the Server … Viele Grüße, Dennis-ſ
Re: [Neo] script: ref2svg
Dennis Heidsiek schrieb am 03.04.2010 21:13: Christian Kluge ſchrieb am 03.04.2010 18:15 Uhr: Eine Frage an die, die mehr über den Server wissen: Meines Wissens ist Ben die einzige Person, die wirklich Ahnung vom Server hat … Ist Perl installiert? Meines Wissens läuft auf dem Server ein älteres Ubuntu – ist da Perl in der Standardvariante mit dabei? Wenn ja, könnte ja das Makefile für die Grafiken ergänzt werden. Die 404-Seite liefert diese Statusinformationen: Apache/2.2.11 (Ubuntu) DAV/2 SVN/1.5.4 PHP/5.2.6-3ubuntu4.5 with Suhosin-Patch mod_python/3.3.1 Python/2.6.2 mod_ruby/1.2.6 Ruby/1.8.7(2008-08-11) mod_ssl/2.2.11 OpenSSL/0.9.8g Server at neo-layout.org Port 80 Oder wir ergänzen erst das Makefile, sehen ob es klappt und wenn nicht: nette Rückfrage beim Master of the Server … Oder so, hoffentlich ist die Ausgabe oben unvollständig. Mit freundlichen Grüßen Frakturfreak -- Wenns halt war, wies halt war, irgendwie wars, denn noch nie wars, dass es nicht irgendwie war. Mein Blog: http://frakturfreaks-kleine-dinge.1on.de/ signature.asc Description: OpenPGP digital signature
Re: [Neo] script: ref2svg
Am 03.04.2010 12:49, flüsterte Knittl ohne Majuskeln: ps. wir sollten uns echt ein format für die referenz überlegen, welches einfacher zu parsen ist … Für Neo 3 sollten wir IMHO für die Referenz auf eine Darstellung gehen ähnlich wie sie bei NeoVars üblich ist: Scancode (E₁,E₂,E₃,E₄,E₅,E₆) mit Eₓ als Unicodeangabe (da systemübergreifend gleich, fehlende Zeichen in der Schriftart stören nicht). Für Funktionen wie Pos1, Entf usw. müsste man sich auf ein Keysym einigen, die Linux-Bezeichnung bietet sich natürlich an. Die tastaturartige Referenz zum Ankucken müsste daraus generiert werden können, der Code für die Treiber auch. Die je nach Treiber benötigten Keysyms müssten sich aus der Unicodeangabe ja auch erstellen lassen. Ich habe oft beim NeoVars die Belegung abgekuckt, da die Belegung dort übersichlich ist und es einfacher ging, als mit unserer offiziellen Referenz. Gruß Florian signature.asc Description: OpenPGP digital signature
