-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Preuss schrieb:
>> Ich entdecke gerade, dass du in gui.c
>> das GWEN_GUI als static variable (also prozessweit) ablegen willst,
>
> 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.
Also wir sind uns erst einmal einig, dass die statische Variable
bedeutet, dass es nur ein zentrales GWEN_GUI-Objekt gibt, über welches
dann alle GUI-Rückfragen laufen werden.
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.
> 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.
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.
Klingt für mich eher so, dass du die Phantasie der Anwender und der
anderen Programmierer etwas unterschätzt. Solange es keinen technischen
Grund gibt, eine parallele Benutzung verbieten zu müssen, sehe ich genau
dies: Keinen technischen Grund, durch sowas wie die statische Variable
plötzlich die Existenz mehrerer paralleler callback-Objekt zu verbieten.
> 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.
> [...]
> 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).
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.
Ansonsten dein anfänglicher Einwand:
> 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.
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.
Gruß
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBRbjhmGXAi+BfhivFAQKrPwQAmboHfvK2LrvoXx9DMzbSKTNrwzyRrI7S
rV0a/D7dh9p4wjqcUT2MHkgtCTAmapo8nbD8461RwFD+DNEHRux4UjWzxtgy6FBv
PsKY4mWmgD+ilQcXkS25nws88gYRk8jAeoCynBlfUXf1kmpG/H/ZmBOdm1D7fTB8
yMGhQ3oydSk=
=5unX
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
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
