Seite 1 von 2

Re: An Leonidas

Verfasst: Mittwoch 24. Januar 2007, 18:44
von gummibaerchen
Leonidas hat geschrieben:Wenn ihr einen Editor programmiert, dann bringt das außenstehenden gehau gar nichts. Denn es gibt genug gute Editoren, dass euer Texteditor von niemanden genutzt werden würde.
Aber statt ein neues Projekt wäre es IMHO wesentlich schlauer ein anderes Projekt zu finden, welches etwas ähnlich macht und dies zu verbessern. Das ist in der FOSS-Gemeinde ein bischen eine Krankheit, dass statt ein Projekt perfekt funktionieren zu lassen, kocht jeder seine eiene Suppe und es entstehen zig Projekte die alle das gleiche machen, aber keines kommt in ein Stadium, welches brauchbar ist.
Wenn einer mit dem Gedanken spielt, einen Editor zu schreiben bzw zu erweitern, dann würde ich mal ein Auge auf Scribes werfen.

Ist in Python geschrieben, erst bei Version 0.3 und hat noch genügend Features offen, die erfüllt werden sollen ;)

Re: An Leonidas

Verfasst: Mittwoch 24. Januar 2007, 18:46
von sape
lunar hat geschrieben: Außerdem ist qt so groß, dass Windows-Nutzer sich nicht über die geringe Größe des Programmes wundern müssen ;)
Hehe, der war echt gut ^^

Kommen wir auf den Punkt

Verfasst: Freitag 26. Januar 2007, 16:24
von Pythonierer
Also, meine Email-Adresse lautet jasonpixel@web.de. Derjenige, der mitmachen will, schreibt doch bitte einfach an diese Adresse und erwähnt vielleicht gleich den Teil, den er beim Projekt übernehmen will.

Cool wär auch, wenn ihr mir die ICQ-Nummer schicken würdet. Dann könnte man Life-Hilfe leisten oder bekommen.
Meine lautet 247-362-636, also haut in die Tasten, sodass wir schon bald starten können.

Verfasst: Freitag 26. Januar 2007, 21:10
von sape
Welches GUI-Toolkit sol den nun verwendet werden?

EDIT: Vielleicht wäre es nicht verkehrt einen neuen Thread mit einer Umfrage zu öffnen. Dann können alle abstimmten und du weißt dann genau was Sache ist, bevor du Energie in ein Projekt reinsteckst das niemanden interessiert.

Verfasst: Freitag 26. Januar 2007, 21:31
von BlackJack
Alternativvorschlag: Die einzelnen Programme so planen, dass GUI und Logik getrennt sind, dann kann man verschiedene GUIs, von Text, Urwid über Tkinter, Gtk und Qt bis Weboberfläche, daran anbinden.

Verfasst: Samstag 27. Januar 2007, 08:47
von EnTeQuAk
Alternativvorschlag: Die einzelnen Programme so planen, dass GUI und Logik getrennt sind, dann kann man verschiedene GUIs, von Text, Urwid über Tkinter, Gtk und Qt bis Weboberfläche, daran anbinden.
Sollte man das nicht immer versuchen?

Gut das ist nun wirklich nicht sehr einfach -- sollte aber gehen.

Ist doch exakt wie bei der Webprogrammierung... so wenig wie nötig Programmlogik in die Templates ;)

Ich denke, das auch auf GUIs anzuwenden, die mehrere voneinander unabhänige Programme darstellen sollen, ist wirklich nicht verkehrt.

Nun gut ich muss beichten, das ich bisher kaum bis gar nicht mit GUIs zu tun gehabt habe... vllt. stell ich mir das auch zu einfach vor.


Ne Abwechslung währe es allerdings. Ich schau mal. Ich denke, ich werde mich einfach mal bei dir melden.

Allerdings würde ich -- MEINE MEINUNG -- das ganze eher auch wie ein "Lehrprogramm" stricken. Oder zumindest den Personen, die es ausführen die Möglichkeit zu bieten zu lernen, ohne das sie den Quellcode direkt anschauen müssen.

Es sollte möglich sein, die Funktionen entsprechend erklärend zu beschriften und diese mit wunsch auf einen "Erklären" Button die Erklärung wohlformatiert anzuzeigen.

vllt. ist das auch wieder zu hoch gedacht... aber irgentetwas "persönliches" sollte das ganze schon haben. IRgenteinen Nutzen -- außer das die Mitmachenden etwas lernen --.


MfG EnTeQuAk

Verfasst: Samstag 27. Januar 2007, 10:42
von BlackJack
EnTeQuAk hat geschrieben:
Alternativvorschlag: Die einzelnen Programme so planen, dass GUI und Logik getrennt sind, dann kann man verschiedene GUIs, von Text, Urwid über Tkinter, Gtk und Qt bis Weboberfläche, daran anbinden.
Sollte man das nicht immer versuchen?
Sollte man, wird aber oft nicht gemacht. Gerade bei Anfängern kommt oft Code, bei dem zum Beispiel Callbacks bei Buttons ein Ergebnis berechnen und dieses dann auch gleich selbst irgendwo in die GUI schreiben. Das ist für den Anfang ja auch erst einmal das naheliegendste.

Und dann gibt's noch die Umsteiger von gewissen “GUI zusammenklicken und ein paar Funktionen reinschreiben”-Entwicklungswerkzeugen, die haben diese Trennung auch nie gelernt.

Verfasst: Samstag 27. Januar 2007, 13:50
von gummibaerchen
BlackJack hat geschrieben:Sollte man, wird aber oft nicht gemacht. Gerade bei Anfängern kommt oft Code, bei dem zum Beispiel Callbacks bei Buttons ein Ergebnis berechnen und dieses dann auch gleich selbst irgendwo in die GUI schreiben. Das ist für den Anfang ja auch erst einmal das naheliegendste.

Und dann gibt's noch die Umsteiger von gewissen “GUI zusammenklicken und ein paar Funktionen reinschreiben”-Entwicklungswerkzeugen, die haben diese Trennung auch nie gelernt.
Aber das ist ja auch erstmal das schnellste.

Ansonsten muss man ja die ganzen Funktionen bauen, und dann immer noch ein extra Programm für jedes GUI-Toolkit.

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.

Verfasst: Samstag 27. Januar 2007, 14:34
von BlackJack
gummibaerchen hat geschrieben:Aber das ist ja auch erstmal das schnellste.
Das rächt sich aber auch ganz schnell wenn es sich um echte Programme handelt und nicht nur um Spielereien. Und oft werden aus Spielereien auch echte Programme.
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?
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.

Verfasst: Samstag 27. Januar 2007, 16:55
von sape
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

Verfasst: Samstag 27. Januar 2007, 17:57
von BlackJack
sape hat geschrieben:Wie persönlich würdest du das lösen mit dem Buffer?
Ich verstehe das Problem nicht so ganz. Falls Du damit sagen wolltest, dass man das Programmieren von *GUI-Elementen* nicht von der GUI trennen kann, dann ist das irgendwie klar.

Verfasst: Samstag 27. Januar 2007, 18:19
von sape
Naja, ich habe dich so verstanden das du meintest, das man ein Programm schreibt das ohne GUI lauffähig ist (Also Logik ist getränt von dieser) und dann ein Frontend mit einem GUI-Toolkit dafür schreibt. Mit meinen bisherigen Wissenstand ist das nicht in *allen* fällen möglich (z.B. wenn man einen IDE schreibt).

Ich wollte eigentlich Wissen ob es Techniken gibt die immer garantieren das so eine strikte Trennung von Logik und GUI möglich ist und ob so immer Sinnvoll ist? (Wie in dem letzten Abschnitt mit den buffer und einer abstrakten buffer klasse)

Naja, ist eigentlich auch egal und Off-Topic.


lg

Kommt auf den Punkt

Verfasst: Sonntag 28. Januar 2007, 18:33
von Pythonierer
Also wir sind mittlerweilen zu dritt, das ist ja schonmal ein Anfang.

Natürlich können wir übrigens verschiedene GUIs verwenden, denn kompiliert sieht man das eh nicht mehr.

Wer jetzt noch mitmachen will oder Fragen hat, der schreibt mir am besten direkt in ICQ oder per Email, da kann man besser antworten als im Forum.

Also, danke nochmals, aber weitet das ganze nicht unnötig aus.

Sers.

Re: Kommt auf den Punkt

Verfasst: Sonntag 28. Januar 2007, 18:43
von Leonidas
Pythonierer hat geschrieben:Natürlich können wir übrigens verschiedene GUIs verwenden, denn kompiliert sieht man das eh nicht mehr.
Wie meinen? Was hat das Kompilieren mit dem Aussehen der GUI-Elemente zu tun?

Re: Kommt auf den Punkt

Verfasst: Sonntag 28. Januar 2007, 18:58
von sape
Leonidas hat geschrieben:
Pythonierer hat geschrieben:Natürlich können wir übrigens verschiedene GUIs verwenden, denn kompiliert sieht man das eh nicht mehr.
Wie meinen? Was hat das Kompilieren mit dem Aussehen der GUI-Elemente zu tun?
Das würde ich auch mal gerne Wissen!

Re: Kommt auf den Punkt

Verfasst: Sonntag 28. Januar 2007, 19:09
von gummibaerchen
sape hat geschrieben:
Leonidas hat geschrieben:
Pythonierer hat geschrieben:Natürlich können wir übrigens verschiedene GUIs verwenden, denn kompiliert sieht man das eh nicht mehr.
Wie meinen? Was hat das Kompilieren mit dem Aussehen der GUI-Elemente zu tun?
Das würde ich auch mal gerne Wissen!
Ich auch!

Re: Kommt auf den Punkt

Verfasst: Sonntag 28. Januar 2007, 19:30
von pyStyler
gummibaerchen hat geschrieben:
sape hat geschrieben:
Leonidas hat geschrieben:
Pythonierer hat geschrieben:Natürlich können wir übrigens verschiedene GUIs verwenden, denn kompiliert sieht man das eh nicht mehr.
Wie meinen? Was hat das Kompilieren mit dem Aussehen der GUI-Elemente zu tun?
Das würde ich auch mal gerne Wissen!
Ich auch!
ich ebenfalls

Verfasst: Sonntag 28. Januar 2007, 19:30
von EnTeQuAk
Natürlich können wir übrigens verschiedene GUIs verwenden, denn kompiliert sieht man das eh nicht mehr.
Hier wird nichts kompiliert! :) -- außer als zusätzliche Version für Windoof-Benutzer, die zu Faul sind Python zu installieren...


Wenn du da an etwas anderes gedacht hast... ne Danke!

Wäre trotzdem mal schön, wenn du meine ICQ-Authorisierung annehmen würdest :=)

Verfasst: Sonntag 28. Januar 2007, 22:03
von CrackPod
Ich habe sowieso vor einen leistungsfähigen Vocabeltrainer zu schreiben, deswegen werd ich mich hier mal ins Projekt mit einklinken.
Allerdings habe ich bis jetz noch keine Erfahrung mit GUIs...
Was ich noch Vorschlagen würde, wäre folgendes: Wir benutzen Gobby zum programmieren.

LG Tobi

Verfasst: Sonntag 28. Januar 2007, 23:00
von name
CrackPod hat geschrieben:Ich habe sowieso vor einen leistungsfähigen Vocabeltrainer zu schreiben, deswegen werd ich mich hier mal ins Projekt mit einklinken.
Allerdings habe ich bis jetz noch keine Erfahrung mit GUIs...
Was ich noch Vorschlagen würde, wäre folgendes: Wir benutzen Gobby zum programmieren.

LG Tobi
hrhr, ich hab einen kleinen Vocabeltrainer in wxPython angefangen, wenn du willst kannst du daran anknuepfen/mitmachen, wenn du dbs kannst waer das gut, weil ich das nicht kann :)