Moin, On Thursday 25 January 2007 12:23, Christian Stimming wrote: [...] > Im Prinzip okay. Nur eine Unklarheit: Wie kommt denn die Verknüpfung vom > AB_BANKING-Objekt zum neu gesetzten GWEN_GUI-Objekt zustande? Sprich, > woher weiß das AB_BANKING Objekt, von welchem GWEN_GUI-Objekt es nun die > callbacks aufruft? .... oooooh. Ich entdecke gerade, dass du in gui.c > das GWEN_GUI als static variable (also prozessweit) ablegen willst, und > deshalb in gui.h die tatsächlichen Aufrufe wie GWEN_Gui_MessageBox dann > ohne eigenes GWEN_GUI Objekt aufgerufen werden. > > Uuuups. > > Das finde ich, sorry, gar nicht gut. Ich bitte imständig darum, dass du > gerade bei dieser Interaktivitäts-Sache die Interaction-Funktionen > *immer* mit zugehörigem Objekt aufrufst. Dass also ein AB_BANKING-Objekt > auch (woher auch immer) einen Pointer auf sein eigenes GWEN_GUI-Objekt > hat und dieses bei jedem Aufruf einer Interaction-Funktion auch übergibt. [...]
Da bin ich absolut dagegen: Ein GWEN_GUI-Objekt hat von sich aus ueberhaupt keine Verbindung zu einem AB_BANKING_Objekt. Das geht auch schlicht nicht, weil GWEN_GUI auch von Teilen verwendet wird, die ueberhaupt keine Verbindung zu AqBanking haben. Ein GWEN_CryptToken beispielsweise haengt ueberhaupt nicht ab von AqBanking, darf also auch nicht dessen Typen benoetigen. Man moege sich vor Augen halten, wozu GWEN_GUI eigentlich dient: Es soll lediglich Benutzer-Interaktion uebernehmen. Das kann nur koordiniert funktionieren, wenn es eine zentrale Instanz gibt - naemlich die Anwendung, von der es pro Prozess eben auch nur eine gibt - die im Auge behaelt, welche Progress-Widgets gerade geoeffnet sind bzw. gerade auch angezeigt wurden. Der Benutzer kann schlecht auf mehrere Eingabe-Aufforderungen gleichzeitig eingehen, daher macht es ueberhaupt keinen Sinn, mehrere GUI-Verwalter gleichzeitig zu betreiben. Man wird auch kaum mehrere AB_Banking-Objekte gleichzeitig betreiben, die alle eine eigene, andere GUI-Implementierung benoetigen. Der Sinn von GWEN_GUI ist ja gerade, nur eine Stelle zu haben, an der Benutzerinteraktion von der Anwendung abgefangen werden muss. Die Anwendung erklaert alleine und zentral, wie die Interaktion ausgefuehrt werden soll, und dem Aufrufer der GUI-Funktionen hat es egal zu sein, wo das wie letztlich implementiert ist (das ist doch das Prinzip in AqBanking: Es soll mit Konsolen-Fontends genauso funktionieren wie mit QT- Fox oder GTK-Frontends). Umgekehrt steht Dir der Weg aber natuerlich frei, eine Bindung an ein bestimmtes Objekt - sei es ein AB_BANKING-Objekt oder ein Gnucash-Objekt - herzustellen. Bei QBankManager und KMyMoney verzichte ich darauf, aber diese Moeglichkeit besteht nichtsdestotrotz. [...] > apps) dazu gezwungen, so zu programmieren, dass man auf diese statische > Variable eingestellt ist. [...] Ich habe inzwischen zwei Anwendungen angepasst, alle Plugins sowie alle Backends. Ich habe dabei keine Schwierigkeiten gehabt. Es macht naemlich fuer die Anwendung oder die Plugins ueberhaupt keinen Unterschied, wieviele Objekte eigentlich dahinterstecken (mehrere verteilte oder ein zentrales), wenn ich einfach GWEN_Gui_ProgressStart() aufrufe. Im Gegenteil: Der Aufrufer muss sich ueberhaupt nicht dafuer interessieren, sondern ruft einfach die Funktion auf. GWEN_Gui_ProgressStart() beispielsweise liefert einfach nur ein ID zurueck, und das ist alles, was der Aufrufer wissen will, wenn er anschliessend GWEN_Gui_ProgressAdvance(), GWEN_Gui_ProgressLog() oder GWEN_Gui_ProgressEnd() aufrufen will. Ob die Implementierung dazu anschliessend 1, 100 oder gar kein Widget erzeugt, ist dem Aufrufer egal, das ist nicht seine Sache. [...] > statischen variable dagegen würde es ein riesen-Durcheinander geben: wer > ist dann für delete von welchen Objekten zuständig; was passiert, wenn > das zweite Fenster dann doch abgebrochen wird und das erste wieder > benutzt wird oder doch andersrum; etc. [...] Wie gesagt, nach meiner Erfahrung mit den zwei Anwendungen gibt es ueberhaupt kein Durcheinander, vor allem eben auch dadurch, dass es eine zentrale Instanz gibt, die ueberwacht, welche Fenster aufgemacht wurden. Im QT-Frontend habe ich das beispielsweise so geloest, dass GWEN_Gui_ProgressStart() intern ein neues Progress-Objekt erstellt. Dieses enthaelt einen Zeiger auf ein ProgressFenster. Diese ProgressFenster wurde entweder durch diesen Aufruf von GWEN_Gui_ProgressStart() erzeugt, oder durch einen vorangegangenen (das macht fuer den Ablauf keinen Unterschied). Wenn nun also GWEN_Gui_ProgressEnd() aufgerufen wird, diskonnektiert mein Frontend einfach die Verbindung zwischen dem Progress-Objekt und dem ProgressWidget. Beim Widget kann ich dann beispielsweise einfach das WS-Flag DESTRUCTIVE_CLOSE setzen und muss mich anschliessend nicht mehr darum kuemmern, wann das Widget geloescht wird (das macht dann QT fuer mich). Genauso wenn das Fenster geschlossen wird: Normalerweise wird das eh nicht erlaubt, solange nicht GWEN_GUI_ProgressEnd() aufgerufen wird. Passiert das aber aus irgendwelchen Gruenden doch, diskonnektiert sich das Widget im Destruktor einfach selbst vom Progress-Objekt und es gibt ebenfalls keine Frage, wer was loescht. Fuer jedes GWEN_Gui_ProgressStart() muss es ein GWEN_Gui_ProgressEnd() geben, und zwar mit der entsprechenden ID. Aber selbst, wenn das nicht der Fall ist - wegen eines Bugs im Plugin oder in der Implementierung - ist das schlimmste Problem, das auftreten kann, das ein Fenster offenbleibt (bis der User es manuell schliesst). Dies ist aber bei AqBanking auch schon wieder nahezu ausgeschlossen, weil ja waehrend der Ausfuehrung der Jobs zum Ende GWEN_Gui_ProgressEnd() fuer diese Ebene aufgerufen wird, und in meinem QT-Frontend werden dabei jeweils tieferliegende, eventuell noch offene Progress-Objekte, automatisch geschlossen. Fazit: Die praktische Erfahrung zeigt bisher, dass es so, wie es derzeit implementiert ist, am besten funktioniert. Gruss Martin -- "Things are only impossible until they're not" AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Aqbanking-devel mailing list Aqbanking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
