Hi, Am Samstag, 8. April 2006 20:34 schrieb M. Dietrich: > > Nein, überhaupt keine Idee. Wenn --with-frontends="cbanking..." angegeben > > ist, müsste "make" doch auch in die Verzeichnisse src/frontends/cbanking > > und die anderen wechseln, und dort jeweils das libcbanking.la etc > > erstellen. Bist du sicher, dass das nicht geschieht? Von diesem Problem > > hab ich noch nie gehört. > > dann habe ich vielleicht eine falsche vorstellung, was ein frontend > ist. die datei existiert tatsaechlich. kannst du mich zur > dokumentation leiten, wo erlaeutert ist, was ein fe ist? fuer mich > waere das, wenn es eben ui bezogen console, qt, kde, gtk gibt eine ui > wie zB der wizard. dieser liegt aber nach dem make nur als qt vor...
http://linuxwiki.de/AqBanking Ein wizard geht über den allgemeinen Code vom "frontend" noch deutlich hinaus. Deswegen haben wir den nur für qt. Für die console gibts ansonsten src/tools/aqbanking-tool sowie ein aqhbci-tool unterhalb von src/plugins/backends/aqhbci > > > keiner eine idee? habe auch erhebliche probleme mit dem python > > > binding, seit ctypes mit einer neuen version aufgewartet hat, die > > > nicht mehr compatibel ist. nutzt niemand die componenten fuer gtk, > > > console und python? > > > > Die nutzen in der Tat nur wenige Leute. Aber was ist denn mit einem neuen > > ctypes inkompatibel? > > es gibt erhebliche aenderungen. bereits die dll wird anders angezogen. > dies ist bereits eingebaut, allerdings lediglich fuer den mac. dann > ist der zugriff auf die C-variablen scheinbar geaendert. ich bin > leider kein ctypes profi und les mich grad erst ein, aber frueher > schien ein 'cast' auf str zu reichen, nun ist es ein member-zugriff > (also x.value statt str(x)). Äh, wenn ich das richtig verstehe, müsste man die python-wrapper also erheblich umbauen für die neuere ctypes-Version? Kannst du mir ne URL sagen, wo die ctypes-Neuerungen beschrieben sind? > schliesslich bringt ctypes nun einen > generator mit, der leider garnicht mit den aqbanking headern zurecht > kommt. Das ist okay, die bisherigen wrapper sind ja auch alle per Hand gebaut. Und python ist ja objektorientiert, wogegen C das nicht ist; die Verwendung des OO-Konzepts in aqbanking geschieht rein durch Konventionen. Ich bezweifel, dass aus den Konventionen allein ein automatischer Generator die korrekten Klassen für python gleich generieren kann. Also ich bezweifel den Nutzen eines code-Generators für aqbanking generell; da würde ich eher erwarten, dass die existierende manuelle Vorarbeit eben angepasst werden müsste. > ich forsche noch, was da alles schief geht, aber es scheint > eine menge arbeit. der urspruengliche autor des python binding ist > nicht mehr erreichbar, oder? Der ursprüngliche Autor hat sich seit ca. 6-9 Monaten hier nicht mehr gemeldet. Hat sich wohl verabschiedet. Gruß Christian ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Aqbanking-devel mailing list Aqbanking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
