BlackJack hat geschrieben:
Ansonsten muss man ja die ganzen Funktionen bauen, und dann immer noch ein extra Programm für jedes GUI-Toolkit.
Das klingt als ob das irgendwie schlecht wäre. Wenn man die Funktionen nicht unabhängig von der GUI implementiert, wie soll man das Programm dann testen?
Da gebe ich dir auch Recht aber nur teilweise. Wie soll man z.B. nach dieser Methode eine IDE bauen? Ja, man kann und sollte die Logik immer von der GUI trennen, aber gerade beim schreiben einer IDE wird das spätestens dann nicht aufgehen wenn man buffer implementiert.
Z.B. wenn man als buffer Scintilla verwenden will ist das ja keine Große Sache (Die ganze Funktionalität wie Syntax highlighting, etc ist schon integriert und eben auf Scintilla beschränkt und nciht allgemein.). Dort wird einem schon die Arbeit abgenommen. Aber was ist wenn ich z.B. mit dem
``wxRichTextCtrl`` von 0 an einen eigenen buffer programmieren will? Eine richtige Trennung wird da schwer, weil die Teile die mit der Logik zu tun haben, sehr eng an ``wxRichTextCtrl`` gebunden sind/werden müssen bzw. daran angepasst sind/sein müssen und nur damit funktionieren. Das heißt das die Logik ehe nicht unabhängig funktionieren kann, da sie von ``wxRichTextCtrl`` abhängig ist. Und wenn das der Fall ist, hat man schon mal keine Trennung von Logik und GUI -- Die Logik von der GUI trenne heißt für mich, das die Logik unabhängig von der GUI Funktionieren kann. Kann sie es nicht oder ergibt ohne das keinen Sinn, ist es keine Trennung.
Vielleicht ist das aber auch nur eine Eigenart von wxWidget.
Jedenfalls immer wenn man vorhat eine eigenes Widget für wxPython zu schreiben, kommt man nicht drumrum auch ein wenig Logik zu implementieren.
Daher würde ich sagen, das man vielleicht 60% der Logik eines Programms unabhängig machen kann. Der Rest ist an GUI spezifische Sachen gebunden bzw. davon abhängig.
Mal was anderes:
ich habe mich jetzt ein wenig mit aui beschäftigt und mir überlegt wie man ein Derivat von jEdit in wxPython schreiben könnte. Da stellte sich auch die Frage nach der Trennung. Tja, das PugIn System (Ein richtiges bei dem in beide Richtungen Kommuniziert werden kann -> Programm <-> PlugIn.), kann ich schon mal nicht unabhängig vom Toolkit schreiben, da es viel zu sehr von den internen Abläufen des Programms abhängig ist (Diverse Widgets, unter anderem Zugriff auf offene Buffer, Zugriff auf die aui, etc). Genauso mit dem Buffer, der ist auch nicht unabhängig zu kriegen.
BlackJack hat geschrieben:
Oftmals braucht man das ja auch nicht so stark, obwohl sich dadurch die Möglichkeit es auf ein anderes Toolkit zu portieren etwas stärker verbaut.
Und die Möglichkeit der Wiederverwendung von Code und von Unit-Tests sind einem auch verbaut.
Das stimmt. Aber oft ist die Logik nicht so allgemein verwendbar sondern eben auf den GUI teil angepasst.
...
Wie persönlich würdest du das lösen mit dem Buffer?
Ein Weg um eine (Pseudo)-Unabhängigkeit zu implementieren wäre eine Abstrakte klasse, die das ganze Interface definiert. Davon erbt man dann und überschriebt dann die Methoden, das sie z.B. mit Elemten X von GUI-Toolkit Y funktioniert.
So was in der Art.
Ist das Sinnvoll? Wie weit muss man was allgemein halten? Ist es das nicht eher sehr fehleranfällig so eine Flexibilität zu Programmieren, wenn man als Projekt eine IDE hat? Eric4 funktioniert auch nur mit QT und stellenweise ist die Logik auch nicht von der GUI getrennt, weil es nicht zu 100% möglich war/ist.
lg
-- außer als zusätzliche Version für Windoof-Benutzer, die zu Faul sind Python zu installieren...