Zu Spät...

[KDElerin]

Zwei Jahre habe ich nun meine Zeit in diesen Qt Moloch und die stümperhafte KDE Entwicklung investiert... erfolglos. Das Projekt ist einfach nur ein chaotischer Haufen was auch die Ursache von KDE 4.0 war und Qt ist einfach nur schrecklich. Inzwischen kann man KDE4 ja gut verwenden, aber dafür oder darauf entwickeln? Niemals wieder, da kann ich mich ja gleich an VB versuchen.

[mmj]

Und was empfiehlst du?

[Qtler]

KDElerin schrieb:
-------------------------------------------------------
> Qt ist einfach nur schrecklich.

Was ist denn an Qt konkret so schrecklich?

[René L.]

Ich bin mit PyQt (Python + Qt) überaus zufrieden, mit wenigen Zeilen Quellcode hat man eine Applikation mit nativen Widgets auf allen Plattformen.
Und mit Pyinstaller ist das ganze auch noch portabel (kann direkt ausgeführt werden, ohne es installiert zu haben).
Ab 7 MB bist du dabei (Python und alle nötigen Libraries schon inklusive).

[Elektritter]

Ich glaube nicht, dass das näher benannt werden kann ohne offenzulegen dass man (Mehrfachnennungen möglich):

[ ] die vergangenen Kriege GNOME vs. KDE verkrampft aufleben lassen will
[ ] keinerlei Ahnung von C++ hat
[ ] Mit der Komplexität eines Frameworks auf dem Level Qt und Boost (um anderes Beispiel zu nennen) überfordert ist
[ ] man entsetzt entdeckt hat, dass man trotz eines der besten Frameworks auch noch selber knifflige Probleme lösen muß.
[ ] man einfach mal nur dumm rumtrollen will

Das einzige was mir immer wieder anstinkt ist dass man gerade die interessanten Dinge mühsam ohne Doku per RTFS entdecken muss. (Wie zur Hölle baue ich z.b. selber so ein Widget das rechts unten eine Progressbar wie beim Dateitransfer ausspuckt, KNotify gibt es einfach nicht her und der JobServer kann nicht genutzt werden)

Ansonsten: klar, Qt hat Macken. Aber es treibt einen nicht die Tränen in die Augen wie gtk+ oder ist nicht so verschwurbelt wie es BOOST über weite Strecken ist. Ich hoffe mir nur, dass in der SDK vor allem sehr viel mehr als nur die reine Interface-Doku enthalten ist (siehe obiges Beispiel)

Und exception-handling in Qt? Da werden wir wohl sehr sehr lange warten müssen...

Aber natürlich ist man für Details warum Qt schrecklich sein soll (vor allem - im Gegensatz zu was? Signal/Slots hat ja nun mittlerweile jedes größeres Framework) stets offen.

E.

[hb]

> Aber es treibt
> einen nicht die Tränen in die Augen wie gtk+

Ich fülle deine Checkliste dann mal für dich aus:

> [X] die vergangenen Kriege GNOME vs. KDE
> verkrampft aufleben lassen will
> [ ] keinerlei Ahnung von C++ hat
> [ ] Mit der Komplexität eines Frameworks auf dem
> Level Qt und Boost (um anderes Beispiel zu nennen)
> überfordert ist
> [ ] man entsetzt entdeckt hat, dass man trotz
> eines der besten Frameworks auch noch selber
> knifflige Probleme lösen muß.
> [X] man einfach mal nur dumm rumtrollen will

[Hello_World]

Signale und Slots hat mittlerweile jedes Toolkit, aber moc bietet noch viel mehr, insbesondere Introspektion.

[hb]

95% der Zeit wären mir Typ-sichere Signal/Slot Verbindungen wichtiger als die Möglichkeit zur Introspektion.

Das ist ein typisches Beispiel dafür, wie man versucht, Altlasten als Feature hinzustellen.

[ojhafjksahdf]

Was kannst du denn für gute C++ Widget-Bibliotheken empfehlen?

[bertie]

ojhafjksahdf schrieb:
-------------------------------------------------------
> Was kannst du denn für gute C++
> Widget-Bibliotheken empfehlen?

gtkmm hat z.B. typsichere Signale.

[harryF]

Altlasten? Sogar moderne Toolkits wie Cocoa haben dynamische signale/slots. Spaetestens wenn du script-bindings zu Deiner UI machen willst (und welche app will nicht scriptable sein?) wirst Du diese Features schaetzen.

[gyros]

harryF schrieb:
-------------------------------------------------------
> Altlasten? Sogar moderne Toolkits wie Cocoa

Cocoa ist nicht modern, sondern ziemlich alt (~ 20 Jahre).

[Elektritter]

ach, glaub mir, ich habe dieses absurde Spiegelfechten "Gnome vs. KDE" selbst in seinen Hochzeiten nur mit Befremden wahrgenommen (als eingefleischter KDE-Entwickler wohlgemerkt), da lass ich mir das jetzt auch von Dir nicht nachträglich unterstellen.

Es sei natürlich, Du wolltest das der Originalposterin (incl. Trolling) unterstellen. Da trifft es dann wohl eher zu.

Egal:

* Typsicherheit: mir reicht es ehrlich gesagt komplett aus, dass Signale/Slots mit unterschiedlichen Signaturen, sprich, unterschiedlichen Typen, nicht mit einander verbunden werden (können). Typüberprüfung muss nicht nur beim compilieren vorhanden sein, es kann auch einfach mal zur Laufzeit ermöglicht werden. Ist genauso wirkungsvoll.

* gtkmm: ich weiss gar nicht, wie oft ich in den letzten Jahren versucht habe, Qt Anwendungen auch mit einem gtkmm interface zu versehen. Irgendwann gibt man auf, weil man viele Möglichkeiten die QT hat dort erst mehr oder weniger mühselig nachbauen muss. Da habe ich eindeutig besseres zu tun. Und natürlich weiss ich, dass da auch sehr viel Gewöhnung mit drin steckt (siehe ersten Abschnitt).

Alles in allem ist genau diese Diskussion müssig: ich will eigentlich einfach nur wissen, was bitte schön an qt4(!) (nicht qt2 bitte) so schrecklich sein soll. Und irgendwie will mir das hier keiner sagen.

E.

[hb]

Elektritter schrieb:
-------------------------------------------------------
> Es sei natürlich, Du wolltest das der
> Originalposterin (incl. Trolling) unterstellen. Da
> trifft es dann wohl eher zu.

Nein. DIR wollte ich trolling unterstellen. Die entsprechende Passage hatte ich zitiert.

[hb]

ojhafjksahdf schrieb:
-------------------------------------------------------
> Was kannst du denn für gute C++
> Widget-Bibliotheken empfehlen?

Qt _ist_ ein gutes Framework für C++.

[hb]

harryF schrieb:
-------------------------------------------------------
> Altlasten? Sogar moderne Toolkits wie Cocoa haben
> dynamische signale/slots. Spaetestens wenn du
> script-bindings zu Deiner UI machen willst (und
> welche app will nicht scriptable sein?) wirst Du
> diese Features schaetzen.

Ein Feature zu schätzen, wenn man es (mal -- in 2% der Fälle) braucht und darauf festgenagelt zu sein sind zwei verschieden paar Schuhe.

Nehmen wir mal ein völlig analoges Beispiel: Void Pointer Container (wie in C) sind ultra flexibel. Trotzdem nehm ich, wenn ich in C++ programmiere, lieber typsichere Container aus der STL -- und zwar aus gutem Grund. Trotzdem kann ich, wenn es unbedingt nötig ist, immernoch mit void-Pointern rumfrickeln.

Ich habe noch nie einen (echten) C++ Programmier gehört, der meinte, void-Pointer Container wäre irgendwie "besser" als entsprechende STL Funktionalität. Beim MOC siehts auf einmal genau anders rum aus.

Genauso ist die Situation übrigends in gtkmm (Typsicherheit, außer man will es unbedingt anders). Es geht also.

[Thomas W.]

Eins vorweg,
ich finde Qt spitze. Ich entwickle gerade eine Datenbank-Anwendung in Qt, mit PostgreSQL als Datenbank. Das Signals/Slots-Konzept fand ich am Anfang umwerfend, inzwischen bin ich mir nicht mehr ganz so sicher ob Signals/Slots unabdingbar sind, auf jeden Fall sind sie sehr nett und machen die Arbeit um einiges einfacher. Genial an Qt finde ich das Layout-System und den Code-Stil (d.h. viele Enums, aussagekräftige Funktionen etc.).

Typensicherheit kann ich nicht so viel mitreden, da ich selber noch eher Anfänger bin. Ich weiß dass viele sich aufregen, dass Qt mit seinem MOC C++ unnötig erweitert. Manche Sachen hab ich auch noch nicht verstanden, z.B. das Property-System (nicht dass ich's versucht hätte, bis jetzt hab ichs nicht gebraucht).

Was mich an Qt aufregt sind eigentlich nur Bugs. Hier mal ein paar:
- QColumnView ist absolut unbrauchbar, total verbugt, das PreviewWidget hat kein Layout und lässt sich auch nicht deaktivieren
- Die SQL-Klassen sind extrem buggy, warum funktioniert insertRow() und setData() problemlos, insertRecord() aber nicht, obwohl insertRecord() intern das selbe macht?
- Die Docs sind zwar umfangreich, aber sparen an praktischen Tipps. Ich frage inzwischen immer in #qt nach, ob's nicht für Funktion X ne Klasse gibt, bevor ich sie selber programmiere. So habe ich z.B. einmal ne Klasse programmiert, um auf jedem System den Standard-Webbrowser zu finden, nur um herauszufinden dass Qt das schon kann.

[gf]

Versteh ich nicht - wenn Du Typsicherheit willst, dann nimm doch boost signals, ansonsten Qt signale.

[hb]

Es geht um die Kommunikation mit Qt Objekten.

[brat]

weiß nicht was ihr habt, das kommt doch drauf an wie man signale/slots verwendet...