chris109 schrieb:
Zum Grundsätzlichen Design:
Du hast sicher recht, dass GUI und Backend getrennte Prozesse sein sollten, schon allein deshalb, weil das kopieren großer Dateien die GUI störend blockiert. Den Mechanismus mit Signalen werde ich mir mal ansehen.
Die Trennung von GUI und Funktion soll nach Prinzip der [Fassade http://de.wikipedia.org/wiki/Facade] gestaltet sein. Da ich langfristig verschiedene Frontends anbieten möchte. Mein Traum ist unter anderem ein Mediacenter bzw. einen VDR damit auszustatten.
Ja, das sollte mit GObject möglich sein. Das Backend muss dann nämlich gar nicht wissen, welche Möglichkeiten zur Anzeige etc. das Frontend hat, es feuert einfach nur entsprechende Signale, die das jeweilige Frontend (GTK-Anwendung, VDR, etc.) auswertet.
Vom Frage-Antwort-Spiel möchte ich eigentlich nicht abweichen. Das Programm ist immerhin primär für meinen Vater entworfen, der mit umfangreichen Dialogen seine Schwierigkeiten hat. Schon der Speichern-Dialog von Gnome-Programmen überfordert ihn im Grunde. Vielleicht finde ich aber noch eine elegantere Möglichkeit. Auf jeden Fall darf ich dem Benutzer nicht mehr als genau eine Option/Frage gleichzeitig anbieten, auf die er seine Aufmerksamkeit richten kann.
Ok, verstehe. Es ist halt nicht das übliche GUI-Design, daher hatte es mich zunächst etwas irritiert. Aber es soll ja offenbar auch keinen üblichen Zweck erfüllen, und dann macht es natürlich Sinn, ein Design zu wählen, dass am besten passt (sprich: das Dein Vater am besten versteht).
Die Abfragen beim Start sind deshalb so wichtig, weil das Programm von vornherein wissen soll, ob alle Voraussetzungen für einen korrekten Ablauf gegeben sind und dem Benutzer vorher sagen kann ob alles funktioniert oder nicht. Ich sehe aber auch, dass es nicht besonders "gut aussieht" wenn man auf den Code schaut.
Ja, verstehe. Auch nicht das übliche Design, aber in dem Fall mit der Dialog-Abfolge ist es vermutlich auch nicht sehr hübsch, wenn man nach all den Fragen und Antworten auf einmal eine Fehlermeldung bekommt und man von vorne anfangen darf. 😉
Zum Lesen verwendest Du es ja schon, wenn ich mich recht erinnere. Dann musst Du es nur noch zum Schreiben der Konfigurationsdatei auch benutzen.
Noch eine Anmerkung:
Für mich persönlich ist dieses Programm deshalb so interessant, weil die Aufgabe nur technisch sehr simpel ist, der Anspruch aber trotzdem enorm hoch. Technisch könnte man das Problem mit einem Dreizeiler lösen. Der Anspruch ist aber dem Benutzer die Aufgabe komplett abzunehmen und ihm zu ersparen mitdenken oder verstehen zu müssen. Der Computer erledigt die Aufgabe, wenn man die Kamera ansteckt und der Computer weiß was er tut.
Wenn Du noch mehr Ideen oder Vorschläge hast, würde ich mich über Vorschläge oder konkreten Code freuen. Ich weiß ja nicht wie weit Dich die Herausforderung, der ich mich hier stelle, persönlich interessiert.
Ich habe ja, wie in einem früheren Beitrag geschrieben, mit fast der gleichen Motivation angefangen, mir PyGTK anzueignen. Auch da habe ich als erstes ein Kamera-Import-Programm für meine Eltern geschrieben. Das Problem stellt sich mir jetzt so nicht mehr, da meine Eltern eine gute Lösung gefunden haben, deswegen würde ich vermutlich nicht konkret bei Deinem Programm mitarbeiten. Dafür habe ich selbst noch zu viele Baustellen offen. Aber für eine Diskussion über gutes Anwendungsdesign bin ich durchaus zu haben. Wenn Du also im Laufe des Projektes an irgendwelche Fragen kommst, bin ich gerne bereit, mir das einmal anzusehen und zu überlegen, ob ich dazu eine Idee habe.
Liebe Grüße
Fredo
