On Thursday 25 January 2007 17:58, Christian Stimming wrote:
[...]
> Ich halte das für ein GUI-Programm schon aus Prinzip für den falschen
> Ansatz. Die App hat nun mal viele verschiedene Fenster. Bei
> Benutzer-Rückfragen kann irgendeines der existierenden Fenster das
> jeweilige parent-window sein, inklusive jeweiliger Zuständigkeit fürs
> Löschen. Ich erwarte von einem callback-Objekt wie GWEN_GUI, dass ich im
> callback-Objekt abspeichern kann, zu welchem konkreten parent-window
> dieses callback-Objekt denn nun gehört. Das bedeutet zwangsläufig, dass
> das callback-Objekt eben keine zentrale Instanz ist, sondern dass es
> potentiell mehrere davon geben kann. Darin sehe ich genau die
> Wirklichkeit repräsentiert, nämlich die Existenz vieler verschiedener
> Fenster.
[...]
Na und? Das ist Dir doch weiterhin unbenommen? Du kannst doch immer noch
mehrere Fenster gleichzeitig offenhaben? Und welches Fenster das jeweilige
Parent-Window eines eventuell angezeigten Widgets ist, hat doch nichts mit
den GWEN_GUI-Funktionen zu tun?
Wie beschrieben erzeuge ich bei GWEN_Gui_ProgressStart() ja auch meine
internen eigenen Progress-Objekte, und merke mir zu denen auch - innerhalb
dieser Objekte - welches Widget dazu gehoert. Das kannst Du ja genauso
machen. Es ist nur nicht Aufgabe der Schnittstelle von den Plugins zum GUI
sich zu merken, wer wann wie welches Widget erzeugt.
Das Plugin sagt nur: "Ich beginne jetzt eine Operation mit so und so vielen
Schritten, und werde Dir ab und zu sagen, wenn ich einen Schritt weiter bin
(werde Dir dazu auch jeweils die ID mitteilen). Ausserdem werde ich eventuell
noch ein paar Logmeldungen ausgeben. Zeig das dem Benutzer."
Wie Du das in der GUI dann darstellen willst, ist doch Deine Sache?? Die
Funktion GWEN_Gui_ProgressStart() muss eine ID zurueckgeben, das ist die
einzige Forderung vom Plugin. Was da im einzelnen dahintersteckt,
interessiert das Plugin ueberhaupt nicht. Das Plugin wird nur diese ID im
weiteren verwenden, um darauf zu referenzieren, beispielsweise bei
GWEN_Gui_ProgressEnd().
Mit der statischen Variable wird also in keinster Weise festgelegt, welches
Widget wann wie von wem dargestellt wird (oder aber nicht dargestellt wird),
oder wer wessen Parent ist. Es gibt nur eine zentrale Stelle, an der der
Anwendung *gemeldet* wird, dass irgendein Plugin (oder wer auch immer) eine
Operation startet.
Wenn Du also weitere Informationen zum Progress-Objekt ablegen willst: Das
kannst Du doch weiterhin machen, wie Du lustig bist. Entscheidend fuer das
Plugin ist nur die ID.
Das GUI-Interface geht ja sogar so weit, dass es selber ueberhaupt keine
Progress-Objekte definiert. Da ist die Anwendung voellig frei. Ich fuer
meinen Teil verwende Progress-Objekte (wie beschrieben), und das muesstest Du
sicher auch tun, wenn Du Dir jeweils die Parent-Widgets etc merken willst.
[...]
> Warum denn nicht? Es kann doch durchaus ein AB_Banking-Objekt mit einem
> Dateiimport beschäftigt sein (von parent-window W1 aus) und ein weiteres
> mit einem HBCI-Saldoabruf (von parent-window W2 aus). Diese beiden
> Aktionen würden sich nicht einmal auf Ebene der config-Datei in die
> Quere kommen. Die einzigen wirklich zu vermeidenden parallelen Instanzen
> sind Schreibzugriffe auf die Dateien - und dafür gibts ja die lockfiles.
[...]
Und das kannst Du weiterhin machen, wenn Du willst. Die GWEN_GUI-API trifft
darueber ueberhaupt gar keine Aussagen, verbietet es also auch nicht.
[...]
> Klingt für mich eher so, dass du die Phantasie der Anwender und der
> anderen Programmierer etwas unterschätzt. Solange es keinen technischen
[...]
Das ist ja nun wirklich Unsinn. Ich bin selber Programmierer, und inzwischen
ebenfalls einige Jahre dabei. Ich habe dabe genuegend Dinge gesehen, die mich
sicher nicht gelehrt haben, zu unterschaetzen, was Programmierer alles mit
einer API anstellen koennen :-)
[...]
> > 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,
>
> Aber da ist GWEN_GUI die falsche Stelle dafür! Die App hat durchaus so
> eine zentrale Instanz, aber das ist die event-loop des darunterliegenden
> Toolkits. Alles, was darüber kommt, sollte eine Parallelität erlauben.
[...]
Wie beschrieben: Die API verbietet ueberhaupt nicht die parallele Ausfuehrung.
[...]
> Du willst nur genau ein progress-Fenster offen haben? Dann mag das ja
> gehen. Aber das war nicht mein Beispiel in meiner vorigen Mail. Da
> redete ich von zwei parallelen AB_Banking-Aktionen, die jeweils
> unterschiedliche parent-windows haben. In deinem Beispiel ist also das
> erste progress-Objekt mit parent-window W1 aufgemacht worden, und jetzt
> wird ein zweites mit einem anderen parent-window aufgemacht - das geht
> jetzt doch gar nicht.
[...]
Nein, ich will nicht API-gemaess nur ein Fenster auf haben. Ich selbst will
natuerlich schon moeglichst viele Progress-Stufen in einem Fenster sammeln,
aber das ist eben *meine* Implementierung. Das ist nicht in der API von
GWEN_GUI festgelegt.
[...]
> Das muss doch nicht eine Verbindung von AB_BANKING und GWEN_GUI
> bedeuten. Ich geh nur auf die Barrikaden wegen der statischen Variable
> anstelle eines jeweils übergebenen pointers. Also in einem
> GWEN_CryptToken dann eben anstelle GWEN_GUI_msgBox("foo", "bar");
> stattdessen GWEN_GUI_msgBox(gui_object, "foo", "bar"); und das
> gui_object muss dann eben vorher bei dem Aufruf des GWEN_CryptToken mit
> übergeben worden sein. Ein kleines bisschen mehr Schreibarbeit, aber nun
> wirklich kein technisches Hindernis.
[...]
Von wegen "ein kleines bischen"...
Das CryptToken - wie jedes andere Plugin - interessiert sich ueberhaupt nicht
fuer den Pointer. Dennoch muesste es diesen Pointer vor allem bei jedem
Funktionsaufruf mitfuehren (als Argument). Und das gilt nicht nur fuer das
CryptToken: Auch alle Gwen-Module, die ProgressStart() verwenden, muessten in
den Funktionen einen Pointer auf das GUI-Objekt haben. Und genauso die
Funktionen in Libchipcard. Das macht fuer mich einfach keinen Sinn, weil der
theoretische Mehrwert, den man sich vielleicht ueberlegen koennte, diese
Nachteile einfach nicht aufwiegt.
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
