Das deutsche Python-Forum

@philistion: Die Quelle sagt nur, dass der formale Standardisierungsprozess 1991 begann, nicht aber, dass (wie von Dir behauptet) „C++ ISO-Standard erstmalig 1991 verabschiedet wurde“. Der erste offizielle Standard stammt aus dem Jahr 1998, und damals waren beileibe nicht alle Implementierungen standardkonform.

Im Übrigen hast Du mehr aus meinen Beiträgen heraus gelesen, als drin stand, lies meinen ersten Beitrag nochmal. Ich habe nicht gesagt, es wäre „unmöglich“, Qt mit C++ zu programmieren. Ich habe gesagt, dass C Kenntnisse weder bei C++ noch bei Python helfen, und dass es insofern völlig egal ist, welche Sprache man lernt. Ich halte Qt-C++ durchaus für beherrschbar, es ist nur eben weitaus weniger komfortabel als Python. Und da die C-Vorkenntnisse sowieso nicht hilfreich sind, kann man dementsprechend auch gleich die komfortablere Programmiersprache lernen ...

Also was ich damit sagen wollte, ist dass eben durch den Beginn des Standardisierungsprozesses im Jahr 1991 auf den C90 Standard Bezug genommen wurde. Das war, wie aus meinen Beiträgen ersichtlich, der Punkt auf den ich hinaus wollte.

Aber eigentlich geht es mir gar nicht um die Details der C++-Standardisierung.

Wir sind anscheinend anderer Meinung über den Nutzen der Programmiersprache C zum Erlernen des C++ Umfangs, der zur Qt Programmierung notwendig ist:

Ich denke, es bietet einen großen Vorteil, da man Qt im Grunde in "C" programmiert und abgesehen von Klassen recht wenig C++ braucht. Deshalb bringen C-Kenntnisse für die Qt-Programmierung eben einen deutlichen Vorteil.

Abgesehen davon kann man natürlich sagen, dass für viele Aufgaben, Python viel schneller und mit weniger Aufwand zum Erfolg führt und man schlussendlich, wenn man diverse komplexe Programme schreiben will, durch das Neulernen der Sprache Python schneller mit Qt eine Großanwendung auf die Reihe bringt, wie vielleicht mit C++ und Qt.

So unterschiedlich sind unsere Ansichten also eh nicht..

@philistion: Oh, also in einem Punkt sind unsere Ansichten sehr verschieden: Die Aussage, dass man Qt im Grunde in "C" programmiert, finde ich völlig absurd. C ist das letzte, was mir beim Blick auf ein typisches Qt/C++-Programm in den Sinn kommt. Eher denke ich noch an Java oder C# ... mit typischen C-Idiomen hat Qt nun absolut gar nichts am Hut.

Achtung "Qt mit Klassen", das war natürlich vereinfachend, aber wenn wir nun anfangen unsere Wörter zu zerpflücken führt das zu nichts mehr.

Qt hauptsächlich in C mit Klassen zu programmieren, heißt eben jene von uns vorhin angesprochenen komplizierteren Syntaxelemente wie Templates, usw. nicht zu verwenden.
Und dann bleibt wirklich nicht mehr so viel übrig, was man als reines C++ bezeichnen würde.

// Addendum: Typisches Beispiel, aus dem KDE Source, Qt mit C++, aber viel Syntax die ein C-Programmierer, der sich in Qt und die Klassen eingelesen hat, nicht verstehen würde, findet sich hierbei nicht (von std namespace / cout mal abgesehen): http://websvn.kde.org/trunk/koffice/kch ... iew=markup

3ff hat geschrieben: Für mich sind Beiträge, wie vom Mitstreiter hyperion, typisch für einen Generationenkonflikt.

Da zu Deinem Beitrag von anderen schon einiges gesagt wurde, will ich nur mal kurz einiges klar stellen:

Ich wollte und will sicherlich keinen Generationenkonflikt lostreten! (Imho eh Quatsch, da das Alter in Sachen Wissen nur einer von vielen Einflussfaktoren ist!) Woher sollte ich wissen, wie alt Du bist? Und selbst wenn würde es meine Antwort eher dann beeinflussen, wenn ich einen sehr jungen Menschen gegenüber hätte, der in seiner sprachlichen Entwicklung noch nicht so weit ist.

@Thema:
Ich habe die Grundfrage Deines Beitrages nicht verstanden und zudem einige Passagen kritisch hinterfragt. Ich finde daran nichts verwerflich oder "elitenhaft"! Vielleicht waren meine Formulierungen auch nicht perfekt, aber Du unterstellt mir hier etwas, was nicht in meinem Sinn lag, noch was imho aus dem Beitrag hervorgeht, wenn man ihn sich nach Deiner Kritik noch einmal durchliest.

QT ist nun mal nicht die Abkürzung für das Rahmenwerk, sondern Qt. Das muss man nicht wissen, sobald man es aber gesagt bekommt, sollte man sich imho zur besseren Verständigung an gängige Nomenklatur halten; bei Abkürzungen erst recht.

Was ein animiertes Bild mit Qt zu tun hat, hast Du immer noch nicht erläutert! Ich habe da ja mal ins blaue geraten - wie wäre es, wenn Du einfach mal meine Gegenfragen beantwortet hättest? Gleiches gilt für diesen "Programmgenerator" - wie bereits erwähnt wurde (und von mir ja auch) ist Qt das eben nicht.

Und eine wirkliche Frage hast Du aus dem ersten Posting ja im nachhinein auch nicht formuliert.

Laut eigener Aussagen hast Du hier im Forum ja schon einiges mitgelesen; dann solltest Du aber auch wissen, dass hier niemand abgecancelt wird. Der Eindruck mag nur dann enstehen, wenn der OP sich unhöflich oder ignorant verhält, allerdings kommt das selten vor und ist in diesen speziellen Fällen eher eine Art "Erziehungs"-masßnahme.

Nun ja, vielleicht hatten "wir" auch nur einen schlechten Start. Aber ich würde mich freuen, wenn Du anstatt es bei dem Meta-Posting über meine Einwände und Nachfragen zu belassen noch einmal drauf eingehen würdest, um evtl. Unklarheiten zu beseitigen und ggf. konkrete Fragen zu beantworten.

@Hyperion,
auch ich hab schon nachträglich einiges zu dem ganzen Mußerständnis gesagt.
Allerdings heiß ich nicht Horst K. und schmeiss alles hin.
Mein Ausgangspunkt war, das ich grobe Vorstellungen vom Paket Qt hatte. ich hatte auch einige beispiele durchgearbeitet wie halloschoenewelt etc.
Nun arbeite ich mit Ubuntu/Linux und eines tages war über synaptic plötzlich Qt4 mit allen Paketen auf meinem PC.
Ich hab auch schon einiges mit tKinter geschrieben aber Qt ist eben besser, als die anderen GUI sei es wxPython, PyGTK etc.
Der Kern von Qt4 ist halt der Programmgenerator, den man (normalerweise) mit uic anspricht.
Dann geht es weiter zum Cpp Kompiler, der Cpp Klassen übersetzt. Diese Klassen muß man in sein jeweiliges Progamm einbinden. das versteh ich unter animieren. Weiterhin benutzt Qt die sogenannten Signale und Slots, um Aktionen in die Bilder zu bringen.
Wenn man nun in Cpp fitt ist, dann kann man auch Bildmasken mit Leben versorgen. Der Signaleditor, wo man mit der Maus die Vrbindungen erzeugt, ist schon super.
Wenn man jetzt allerdings mit Qt und den Klassen, die zur Verfügung stehen, arbeten will, dann muß man schon recht fitt in Cpp sein. Das war/bin ich aber nicht.
Da ich mich aber einigermassen in Python auskenne, liegt doch die Frage nahe, wie kann ich meinen Pyuic4 dazu bringen, mir Pythoncode zu generieren.
Das hab ich mittlerweile rausgefunden, obwohl ich längst nicht fit bin.
Python.org bietet ja die Bibliothek für python an und hier an der Uni Heidelberg ist ein deutscher Server, der auch diese Library vorhält.
Das nutzt aber wenig, wenn man mit Qt arbeitet, denn Qt verwendet andere Biblioteksaufrufe.
Inzwischen hab ich rausgefunden, wie man die Widgets, die Dialogs, die Treeviews etc. anspricht.
Da ich nun gut englisch verstehe(hab etliche Jahre in England gearbeitet), hab ich auch keine Schwierigkeiten bei riverbankcomputing.com die Doku zu lesen.
Ich hab ein Projekt vor der Brust, wo jemand mit Qt was gezaubert hat und dann aber verschwunden ist.
Wenn man mit Qt anfängt, dann muss man/ich schon genau wissen was und wo und wie es geht.
Die Doku zu Qt ist auch sehr mager nach meiner Einschätzung.
Qt und der Programmgenerator bringen schon enorme Vorteile allerdings setzt dies voraus, das man das produkt hinten und vorne kennst.
Das war die Story vom verlorenen Programmierer. Wenn ich weitere Fragen habe, werd ich mich an dies Forum wenden.
Grüße aus dem Odenwald
Fritz

@3ff: Der Kern von Qt4 ist *nicht* der Programmgenerator. Und die Doku zu Qt ist nun wirklich nicht mager sondern im Gegenteil recht umfangreich.

@BlachJack
ich seh das etwas anders. Wir reden auch von PyQt4. Da ist noch viel zu tun von riversidecomputing.com
Wir sind hier in einem Python-Forum nicht im Cpp-Forum.
Die Erklärungen, die die Engländer bringen, zu ihrer Qt-bibliothek, sind nicht in Python, sondern in Cpp.
Wenn Qt4 der durchschlagende Erfolg für Nikia werden soll, dann muß Nokia noch mehrere Schippen drauflegen. Im industriellen Bereich geht es anders zu. Es geht ja nicht nur um einfache Bildchen, sondern
ganze Produktlinien, die weltweit eingesetzt werden.
Da spielt die Wartung der Programme eine ganz entscheidende Rolle. Und die Lizensgebühren etc. pp.
Trolltech geht dieses jahr auf die Messe in München. das reicht nicht, um ihren Qt4 unters Volk u bringen.
ich arbeite jetzt schon einige Tage intensiv mit diesem Produkt und bin begeistert.
In meiner früheren Firma sind etliche leute scho an Qt4 und Qt3 gescheitert, weil sie sich irgendwie im kreis gedreht haben. Deutsche und japanische Firmen zB Siemens oder Hitachi liefern andere Dokumentationen ab für deren Produkte S5 oder die Hitachi-SPS.
Diese kritik hier muß man vertragen können und auch reagiern, schließlich ist Nokia die größte finnische Firma.
Guuude
Fritz

@3ff: Ich glaube nicht dass *Deine* Erwartungshaltung zur Dokumentation für den Erfolg oder Nichterfolg von Qt oder PyQt entscheidet. Die C++-API ist grösstenteils automatisch zu einer Python-API ge"wrapped" worden, d.h. es gibt bestimmte Regeln nach denen man die C++-API und deren Dokumentation auf Python/PyQt anwenden kann. Diese Regeln und Unterschiede sind dokumentiert und da sollte es kein grosses Problem mehr sein, dass die PyQt-Dokumentation hier und da noch ein paar Fragmente C++-Quelltext enthält.

Was andere Hersteller aus dem kommerziellen Umfeld an Dokumentation liefern kann da kein Massstab sein, zumal es auch wesentlich schlechtere gibt. Wenn Nokia auf Qt auf seinen Geräten setzt, kommt man als Programmierer daran nicht vorbei, falls man diese Gertäte als Zielplattform im Auge hat. Und auch bei der nicht ganz perfekten Dokumentation von PyQt ist Python mit PyQt IMHO trotzdem die einfachere und angenehmere Kombination als C++ mit Qt, hat also durchaus Chancen verwendet zu werden.

Das man als Programmierer bei GUI-Toolkits in die Dokumentation des Toolkits schauen muss, und dabei zumindest Funktionssignaturen und Datentypen in der Programmiersprache in der das Toolkit geschrieben wurde lesen können muss, auch wenn man eine andere Sprache zum schreiben der Anwendung verwendet, ist relativ normal. Das passiert einem bei allen grösseren GUI-Toolkits und Sprachen mit Anbindungen an diese. Diese Transferleistung muss man als Programmierer einfach erbringen können.

@BlackJack
Daccord. Was Nokia angeht, hast Du bestimmt recht. Nur arbeite ich nicht für nokia, sondern an einer Anwendung im Bereich Messen-Steuern-Regeln MSR. Ich habe nun einige Tage mit Qt4 gearbeitet und bin eigentlich begeistert grade was den Designer angeht.
Es spielt auch keine Rolle, mit welchen "Sprachkenntnissen" man an Qt rangeht, denn die Pythonbibliothek kann man ohnehin nicht gebrauchen. Die Qt-Programme, die py4uic erzeugt, sind an Python "angelehnt".
Bevor ich mich auf die Python-Reise begab, hab ich das Buch von Martin von Löwis besorgt. Das ist ein Grundlagenbuch und behandelt Python und die verschiedenen GUI-Toolkits zu Python.
Hier im Forum wird öfter die Frage diskutiert, ob es vorteilhaft wäre, Cpp-Kenntnisse zu haben, wenn man mit dem Designer arbeitet.
Ich bezweifel das. Bei meiner Reise durchs Web hab ich auch über Qt-Anwendungen für Ruby gesehen.
Um den Designer ganz nutzen zu können, ist die Denke der Objektorientierten Programmierung erforderlich. Die ist relativ abstrakt und unabhängig von der Programmiersprache.
Der frühere Kollege in meiner ehemaligen Firma, von dem ich das Projekt "geerbt" habe, hat einfach munter drauflos programmiert. Da wurden Bildchen gebastelt, mit Signalen und Slots versehen und der Progammablauf wurde vergessen. Sowas frustriert.
Für den Designer und Qt4 gilt: Learning by Doing und das Rezept Trial and Error hilft nicht weiter.
In der Politik gibts ne Philosophie: Muddling through. Das scheint auch für den Designer zu gelten.
1 schönen Tag noch.
Fritz

3ff hat geschrieben: Es spielt auch keine Rolle, mit welchen "Sprachkenntnissen" man an Qt rangeht, denn die Pythonbibliothek kann man ohnehin nicht gebrauchen.

Wie genau meinst Du das?

Die Qt-Programme, die py4uic erzeugt, sind an Python "angelehnt".

Ich würde hier doch noch mal das uic-Modul erwähnen - das spart einem den statischen Übersetzer... (wurde hier im Forum schon oft diskutiert; und in der gescholtenen PyQt-Doku steht das aber beschrieben )

@Hyperion
bitte geb mit noch etwas Zeit, ich hab heute 1 Dampfbügeleisen repariert und jetzt stehen
noch andere Sachen auf dem Zettel.
Ich hab auch 1 schönes Beispiel gefunden wie riverbankcomputing in Python dokumentiert.
Guude
Fritz

@3ff
Das Herzstück von Qt ist die GUI-Bibliothek, wobei die Qt-Macher die Bibliothek in der Vergangnenheit um grundlegende "jeden Tag"-Programmieranforderungen erweitert haben (Socketprogrammierung, Threads, neuerdings Zustandsautomat etc.). Damit mausert sich Qt eher zu einem Schweizer-Taschenmesser-Ansatz, was gerade unter C++ einiges an Programmieraufwand abnimmt.
Dinge wie Designer (mit Programmgenerator), Ressourcen- und Sprachverwaltung sind eher als tolle Zusatzfeatures zu verstehen (als Teil der eigenen Buildumgebung in C++) und setzen größtenteils auf den von der Bibliothek zur Verfügung gestellten Methoden auf. Du könntest das auch explizit im Quelltext selbst vornehmen (zumindest den ui-Teil hartkodiert).
In Python sind manche der Taschenmesserfunktionen und build-tools unsinnig (weil pythoneigene Abstraktion verfügbar usw.) und daher anders bis gar nicht verfügbar. Im Übrigen erstellt pyuic echten Pythoncode und ist nicht nur an Python angelehnt.

zu den Sprachkenntnissen:
Qt ist ein C++ Kind und entsprechend sind die Dokumentation und die Bsp. seitens Qt für C++ verfasst. Riverbank hat sich nicht die Mühe gemacht, jeden kleinen Schnipsel nach Python zu übersetzen. Ich halte es hier mit BlackJack und bin der Meinung, dass diese Transferleistung der Programmierer erbringen können sollte (Zumal die Minibsp. meist nur geringe Syntaxunterschiede ausmachen).
Als Kind von C++ folgt Qt natürlich dem OOP-Konzept, wer sinnvoll mit Qt programmieren will, sollte grundlegende Praktiken von OOP kennen. Das gilt schon für Python an sich.

zur Organisation:
Für größere Projekte ist einfaches Drauflos-Programmieren immer ein denkbar schlechter Ansatz. Auch für den agilen Entwicklungsansatz ist bei Einsatz mehrerer Entwickler eine Art Superdokumentation nötig, damit eine hohe Orthogonalität erreicht wird und nicht das Projekt in seine Einzelteile zerfällt. Das ist aber eine klassische Frage der Softwareentwicklung und kein Qt-spezifisches Problem.

jerch hat geschrieben:Für größere Projekte ist einfaches Drauflos-Programmieren immer ein denkbar schlechter Ansatz.

Abgesehen davon führt der Designer allein selten zum Ziel.

@3ff
Die Diskussion über CPP-Kenntnisse bezog sich auch nicht auf die Bedienung der bunten Klick-Gui QtDesigner, die wohl jeder wie du sagst per "Learning-By-Doing" hinbekommt, sondern auf das Schreiben von Python-Code für Qt-Anwendungen.

Ich würde dir übrigens auch empfehlen, die Docs von Riverbankcomputing zu konsultieren, dort ist "nahezu alles" (oder sagen wir "der Großteil") Python-gerecht dokumentiert. Wenn man Glück hat sogar teilweise mit Beispielen

@3ff:
Ich bin mir nicht sicher, ob hier nicht ein grundlegendes Verständnisproblem vorliegt. Zumindest suggeriert mir philistions letzter Post eine neue Leseart Deiner Beträge mit diesem Verdacht. Bitte korrigiere mich, wenn dem nicht so ist.

Deine Posts deuten irgendwie auf Qt == Designer == Programmgenerator hin. Dein häufiger angesprochenes "Bild" deute ich als mit dem Designer erstellte Programmoberfläche. Mit dieser Deutung macht zumindest die Überschrift "Qt4 mit Python beleben" Sinn.

Sollte ich Qt in irgendeiner Weise definieren müssen, käme wahrscheinlich etwas wie "plattformübergreifende C++-Bibliothek mit GUI-Schwerpunkt und eigener Entwicklungsumgebung" raus. Dabei deckt die Bibliothek Sparten wie XML, Datenbankzugriffe, Threading, Webzugriff, Graphicsengine (auch mit 3D) und und und ... ab (Ein Blick in die Qt-Dokumentation verschafft da einen Überblick über die erstaunliche Funktionsvielfalt.) All das kannst Du auch ohne Einsatz der mitgelieferten Entwicklungstools nutzen, einfach Editor Deiner Wahl anschmeissen, den Code selber hacken und mit Deiner build-Umgebung kompilieren lassen. Da ist zunächst kein Designer oder Programmgenerator im Spiel.

Der Designer ist eines der mitgelieferten Entwicklungstools und der Einsatz ist optional. Er dient einzig und allein dazu, ein "Bild" Deiner Programmoberfläche/Widgets zu erstellen und mit minimaler Logik zu versehen (Signal/Slot-Verbindungen, Headerdatei). Die eigentliche Programmlogik muss nach wie vor mit Standardmitteln implementiert werden (Slot-Methoden, für das Pythonbinding halt mit Mitteln der Pythonstandardbibliothek ). Desweiteren gibt es Situationen, wo Du mit den Boardmitteln des Designers nicht weiterkommst und die auch die grafische Repräsentation zu Fuß implementieren musst wie oben beschrieben. Für häufiger benutzte Widget-Eigenentwicklungen lohnt sich dann evtl. die Erweiterung des Designers über Platzhalter-Klassen oder sogar die Erstellung eines eigenen Designerplugins.
Der Designer erstellt aus der zusammengeklickten Oberfläche eine XML-Datei, welche dann vom "Programmgenerator" entweder zur Kompilierzeit in C++-Code (uic - user interface compiler) oder zur Laufzeit in Maschinencode (Klasse QUiLoader) übersetzt wird.
Für die Benutzung des Designers sind in der Tat keine C++-Kenntnisse erforderlich, allerdings ist die Vorstellung, wie die Widgets im einzelnen ticken, sinnvoll und machen das Arbeiten damit einfacher.

Soviel aus C++-Sicht, bei den verschiedenen Sprach-Bindings sieht es dann wieder etwas anders aus. So kennt PyQt kein qmake mehr, wozu auch. Aus uic wird bei PyQt pyuic und erstellt nun Pythoncode, der QUiLoader wird als eigenes Modul uic vorgehalten. Die Unterschiede von Qt zu PyQt sind in der Riverbank-Dokumentation erschöpfend erläutert, für alles andere kann ich Dir nur die offizielle Qt-API-Dokumentation empfehlen und hierfür ist mitunter ein minimales Verständnis von C++ von Nöten (welche Du aber aufgrund der Einfachheit der Beispiele mit Deinen C-Kenntnissen auf Anhieb lesen können dürftest)
Für grundlegende paradigmatische Fragen (Wie löst man das jetzt elegant in PyQt?) ist, wie gesagt, das Buch von Mark Summerfield hilfreich. Und bei einer konkreten Fragestellung, welche ich in Deinem Ausgangsbeitrag irgendwie vermisse, natürlich dieses Forum.

Das war jetzt hoffentlich nicht zuviel alter Wein in neuen Schläuchen, wenn ja, dann ignoriere den Beitrag einfach...