Hallo,
möchte mich nun mit Python befassen - habe bisher Pascal mit Lazarus IDE und C# mit Visual Studio geproggt.
Da ich nur Form's Anwendungen schreibe suche ich ein Framework welches einen GUI Designer beinhaltet.
Das Framework sollte unter Linux und Windows laufen und frei sein.
Was gibt es da für Python ?
Gruß Frank
Python Framework inc. Gui Designer
@DL3AD: Qt/PyQt o. PySide/QtDesigner oder Gtk/gi/Glade kämen da wohl in Frage. Wobei ich nicht weiss wie problemlos das mit Gtk/Glade unter Windows läuft. Also es läuft schon, aber wie einfach die Installation ist weiss ich nicht.
Ich entwickele mit PyQt. Das läuft unter allem was wichtig ist und hat einen wirklich guten Gui-Designer.
Der Nachteil ist, dass PyQt + Qt noch mal eine Schippe (an Größe) oben drauf ist.
Allerdings ist das das schon etwas anderes als Visual Studio, wo man nicht unbedingt gezwungen wird GUI und Code zu trennen. Zumindest damals, als ich das noch benutzt habe, konnte man direkt aus dem GUI-Designer den Code für die Events reinbasteln.
Aber ansonsten steht für so ziemlich jedes bekannte Toolkit eine Anbindung an Python bereit, und GUI-Designer gibt es für die Toolkits entsprechend auch.
Python selbst kommt in der Regel (nicht bei jeder Installation, unter Windows jedoch schon) mit Tk, und dafür gibt es mit pygubu einen gut gelungenen GUI-Designer. Allerdings ist Tk eher... ähh.. nicht so hübsch
Der Nachteil ist, dass PyQt + Qt noch mal eine Schippe (an Größe) oben drauf ist.
Allerdings ist das das schon etwas anderes als Visual Studio, wo man nicht unbedingt gezwungen wird GUI und Code zu trennen. Zumindest damals, als ich das noch benutzt habe, konnte man direkt aus dem GUI-Designer den Code für die Events reinbasteln.
Aber ansonsten steht für so ziemlich jedes bekannte Toolkit eine Anbindung an Python bereit, und GUI-Designer gibt es für die Toolkits entsprechend auch.
Python selbst kommt in der Regel (nicht bei jeder Installation, unter Windows jedoch schon) mit Tk, und dafür gibt es mit pygubu einen gut gelungenen GUI-Designer. Allerdings ist Tk eher... ähh.. nicht so hübsch
... Danke für die Antworten.
Hmm ist dass so dass mit dem QT die Gui gebastelt wird dann kommt da eine elendig lange Datei raus die ich dann in den Py code einbinde und dann suche ich mir die die Events raus und bastel die dan in den Py code rein ?
Hmm ist dass so dass mit dem QT die Gui gebastelt wird dann kommt da eine elendig lange Datei raus die ich dann in den Py code einbinde und dann suche ich mir die die Events raus und bastel die dan in den Py code rein ?
Genau, es kommt eine XML-basierende .ui-Datei heraus, die du entweder vorher in Python-Code übersetzen lassen kannst, oder du lässt einfach die Datei zur Laufzeit interpretieren.
Die Signale und Slots kannst du ebenfalls im GUI-Designer bearbeiten. Allerdings habe ich das nie gemacht und weiß nicht ob und wie gut das mit Python funktioniert.
Allerdings kann man sich da einen groben Überblick verschaffen, was ein Objekt für Signale kennt, bevor man tiefer in der API wühlt.
Die Signale und Slots kannst du ebenfalls im GUI-Designer bearbeiten. Allerdings habe ich das nie gemacht und weiß nicht ob und wie gut das mit Python funktioniert.
Allerdings kann man sich da einen groben Überblick verschaffen, was ein Objekt für Signale kennt, bevor man tiefer in der API wühlt.
@DL3AD: Wie lang die XML-Datei ist sollte Dir als Benutzer davon eigentlich egal sein. Bitte keinen Quelltext mehr generieren lassen. Das ist nur ein unnötiger Übersetzungsschritt um den man sich kümmern muss.
@DL3AD: Nein, $GOTT sei Dank nicht. Das macht heute keiner mehr und VS wahrscheinlich auch nur wegen der ganzen VB-Programmierer die das nicht einsehen wollen.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Lies Dir das bitte durch - der User Sophus dachte ähnlich wie Du: http://www.python-forum.de/viewtopic.ph ... 32#p257032DL3AD hat geschrieben:hmm wo liegt denn der Vorteil der Trennung GUI - Code Core - ich muss mir doch alles mühsam zusammenfrickeln :K
Dort werden iirc alle möglichen Vorteile aufgezeigt und erklärt.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
im Prinzip mache ich das ja schon so.
Habe z.B. eine Anwendung in Pascal geschrieben die eine Hardware über eine Netzwerkverbindung steuert (Antennenanlage mit Rotoren verschidene Relais...)
Die einzelnen Funktionen und Proceduren sind Funktionell zur Hardware in verschinene Units aufgeteilt.
In der Main Unit ist dann die Eventbahandlung zur GUI zusammengführt.
Vor jahren hatte ich den Code mal in Purebasic geschrieben - dann auf C# portiert und wiel es nicht unter Linux lief auf Pascal portiert.
Da ich die Codestrucktur unter C# optimirt hatte brauchte ich eigentlich unter Pascal nur die Syntax anpassen.
Schön war unter Lazarus dass ich nur das gewünschte Ereignis anklicken brauchte und der notwendige Code für dass Ereigniss war eingefügt und brauchte nur vervollständigt werden.
Diese Anwendung wollte ich nun als Einstieg auf Python portieren.
Habe z.B. eine Anwendung in Pascal geschrieben die eine Hardware über eine Netzwerkverbindung steuert (Antennenanlage mit Rotoren verschidene Relais...)
Die einzelnen Funktionen und Proceduren sind Funktionell zur Hardware in verschinene Units aufgeteilt.
In der Main Unit ist dann die Eventbahandlung zur GUI zusammengführt.
Vor jahren hatte ich den Code mal in Purebasic geschrieben - dann auf C# portiert und wiel es nicht unter Linux lief auf Pascal portiert.
Da ich die Codestrucktur unter C# optimirt hatte brauchte ich eigentlich unter Pascal nur die Syntax anpassen.
Schön war unter Lazarus dass ich nur das gewünschte Ereignis anklicken brauchte und der notwendige Code für dass Ereigniss war eingefügt und brauchte nur vervollständigt werden.
Diese Anwendung wollte ich nun als Einstieg auf Python portieren.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Ich kenne mich mit Pascal nicht wirklich aus (einige Tage Turbo Pascal so anno '96 - '98 iirc), aber ich bezweifel irgend wie, dass man idiomatisch guten C#-Code eins zu eins nach Pascal portieren kannDL3AD hat geschrieben: Da ich die Codestrucktur unter C# optimirt hatte brauchte ich eigentlich unter Pascal nur die Syntax anpassen.
Du musst Dich schon auf Python einlassen, wenn Du es wirklich sinnvoll lernen und einsetzen willst. Natürlich kann man mit der Portierung eines eigenen Projektes anfangen, allerdings sollte man darauf gefasst sein, dass man es *vielfach* überarbeiten wird. Das fängt bei grundlegenden Konstrukten an, die Pascal gar nicht kennt (Klassen afair) und hört bei diversen Pattern auf, die extrem Sprach spezifisch sind. Man spricht dabei im Kontext von Python von "pythonisch". Beispiele dafür wäre z.B. das Ausnutzen von Duck Typing gegenüber dem heftigen Gebrauch von Klassenhierarchien.
Also: Versuche *nicht* die Syntax eins zu eins zu kopieren, sondern befasse Dich mit den grundlegenden Konzepten und Idiomen in Python. Recherchiere darüber hinaus Libs, die man für Dein Projekt gebrauchen kann und mache nicht alles selbst.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
@Hyperion: TurboPascal kannte seit Version 5 das Schlüsselwort ``object``, ich habe hier noch den „Turbo Pascal 5.5 — Object Oriented Programming Guide“ von 1989. Mit Delphi kam dann 1995 ``class`` dazu.
... dass man sich mit den Eigenarten einer Sprache auseinandersetzen muss ist doch klar Und 1:1 geht ja kaum - wobei C# und Pascal sich sehr ähnlich sind.
Ich schaue mit die Sache mal an - C# war zu Anfang auch nicht so bequem - aber wen man sich mal duchgebissen hat klappt es.
Python scheint interessant zu sein, deshalb will ich es auch mal versuchen.
Gruß Frank
Ich schaue mit die Sache mal an - C# war zu Anfang auch nicht so bequem - aber wen man sich mal duchgebissen hat klappt es.
Python scheint interessant zu sein, deshalb will ich es auch mal versuchen.
Gruß Frank