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!
