wxWidgets vs Qt

Aufgrund der aktuellen "Meinungs-Threads" bin ich doch recht neugierig auf Qt geworden und was es alles im Vergleich zu wxWidgets kann.

Was kann man mit Qt machen, was nicht mit wxWidgets möglich ist und umgekehrt?
Die meisten Leute, die sich für ein Framework entscheiden, wählen sowieso entweder Qt oder wxWidgets.
Etwas, dass mir bisher aufgefallen ist, ist, dass Qt MDI-Applikationen unterstützt - auch unter Linux - dass scheint in wxWidgets bisher nur unter Windows möglich zu sein (auf anderen Plattformen wird das ganze "nur" simuliert - beispielsweise mit Hilfe von Tabs unter Linux und mit Hilfe "normaler" Frames unter MacOS).
Wer kann weitermachen?

Mir geht es hier primär um Fakten, die Qt und wxWidgets voneinander unterschieden wie das obige MDI-Beispiel.

Es wird ja immer behauptet Qt sei mächtiger als wxWidgets - jetzt würde ich halt gerne wissen wo und warum :p

Die Diskussion vom wxWidgets-Thread über native Widgets soll hier nicht mehr aufgerollt werden... Native Widgets kann man entweder als Vor- aber auch als Nachteil sehen (Stichwort Portabilität)... in diesem Thread jedenfalls solls uns egal sein

Obwohl ich C++ Anfänger bin habe ich mal Abwechslung von der Konsole gesucht und habe die beiden Frameworks kurz angetestet. Ich bin zwar der absolute Neuling in C++ aber vielleicht interessiert dich auch mal die Meinung eines Anfängers. Hier mal die Vor-/Nachteile aus meinen Kurztest.

wxWidgets
Vorteile:

Ich kann statisch linken auch wenn ich proprietär entwickle.
Native Widgets.

Nachteile:

habe ziemlich lange gebraucht um alles selbst zu kompilieren
Die Doku gefällt mir nicht.
es wirkt alles irgendwie zusammengeschustert.

Qt
Vorteile:

durch den Qt-Creator ist es super einfach ein lauffähiges Programm zu erzeugen
die Doku in der IDE und auf der Homepage finde ich erstklassig
wirkt alles sehr professionell
sehr große Community
Webkit als HTML Engine
in meinen Augen schon eine Art Industriestandard für plattformunabhängige Entwicklung, da es auch in einigen Stellenausschreibungen verlangt wird.

Nachteile:

der Buildprozess entspricht nicht dem von Standard C++ Programmen
statisches Linken nur durch käufliche Lizenz oder Freilegung des Codes möglich

Da die Nachteile mich nicht sonderlich stören bin ich erstmal bei Qt geblieben.

G hibbes

Mit Qt ist man schneller fertig mit proggen.

wxSkip

AFAIK kann man mit Qt auch statisch linken, sofern man die Objekt-Datei mitliefert. (sagen manche, nicht alle)

fr33g

wxSkip schrieb:

AFAIK kann man mit Qt auch statisch linken, sofern man die Objekt-Datei mitliefert. (sagen manche, nicht alle)

Meines Wissens nach stimmt das.

Artchi

Sowas kann nur ein Anwalt aufklären. Oder sind eure Aussagen jetzt eine Rechtsberatung?

Zeus

Artchi schrieb:

Sowas kann nur ein Anwalt aufklären. Oder sind eure Aussagen jetzt eine Rechtsberatung?

Ist doch verständlich genug?!

http://www.gnu.de/documents/lgpl-3.0.de.html schrieb:

4. Kombinierte Werke
d) Führen Sie eine der folgenden Handlungen aus:
0. Übertragen Sie den korrespondierenden Minimalquelltext gemäß den Bedingungen dieser Lizenz und den korrespondierenden Anwendungs-Code in einer Form und gemäß Bedingungen, die den Anwender erlauben, die Anwendung mit einer modifizierten Version der gelinkten Version neu zu kombinieren oder zu linken, um ein modifiziertes korrespondierendes Werk zu erzeugen, auf eine Weise, wie sie in §6 der GNU GPL spezifiziert ist, um korrespondierenden Quelltext zu übertragen.

1. Verwenden Sie einen geeigneten Shared-Library-Mechanismus, um mit der Bibliothek zu linken. Ein geeigneter Mechanismus ist ein Mechanismus, der (a) zur Laufzeit ein Exemplar der Bibliothek verwendet, das sich bereits auf dem Computer des Anwenders befindet, und (b) mit einer modifizierten Version der Bibliothek, die mit der gelinkten Version schnittstellenkompatibel ist, korrekt arbeiten wird.

Qt ist superscheisse, weil man die Funktionen der geerbten Klassen nicht gescheit neuimplementieren kann.
Die Lizenz ist auch scheisse.

Man kann damit zwar schnell ein Programm fertigproggen, aber wenn es um die Kleinigkeiten geht, dann dauert es Tage bis unmögliche Frustrationen...

scheiss qt schrieb:

... blablabla ...

Heulsuse.

giowck

Warum Qt besser als wxWidget ist (für mich)

- Qt Style Sheets
- Graphics View
- Qt Anitmation Framework
- Phonon
- usw...

siehe http://doc.qt.nokia.com/4.7-snapshot/index.html

l'abra d'or

scheiss qt schrieb:

Qt ist superscheisse, weil man die Funktionen der geerbten Klassen nicht gescheit neuimplementieren kann.

Das wäre mir neu...
Konkretes Beispiel, oder ist das nur unkontrollierbares Getrolle?

Was ich damit meine ist, dass man die Methoden aus fertigen Klassen nicht kopieren kann wegen den ganzen Q_Q(...) und so ein dummes Zeug...

Wenn ich ein Event aus irgendein Widget neuimplementiere, dann gehen die ihre ursprüngliche Funktion nicht mehr weil es sich nicht mit copy&paste identisch kopieren lässt.....

Hab falsch formuliert, also:
weil man die Methoden der qt-Klassen nicht in geerbten gescheit neuimplementieren lässt, wegen den ganzen Q_T(...) und so ein kackzeug

l'abra d'or

Na wahnsinn...

clas Button : public QPushButton
{
Q_OBJECT
void mousePressEvent(QMouseEvent* e) {
    if( specialTest() ) {
        doSomeSpecialStuff()
    } else {
        QPushButton::mousePressEvent(e);
    }
}
};

Und schon macht der button nur dann eigenes Zeug, wenn ich es will, ansonsten macht er das was auch ein QPushButton macht. Und so und nur so erweitert man eine KLasse, Copy&Paste hat kaum was mit ordentlicher Programmierung zu tun...
Für alles andere, was hinter Q_D (jaja, kein Q, kein T...) steckt: das schimpft sich "PIMPL", wg. binary compatibility.
Mit ordentlicher Kapselung würdest du da auch nicht rankommen, was darin steckt. Datenmember gehören in den private-Bereich, und für das was du erreichen können musst gibt es (teilweise protected, für Ableitung) getter.

Haha, klingt so, als ob "scheiss qt" erstmal programmieren lernen sollte.

Copy&paste aus basisklassen...

Also doch ein troll.

jaf

[quote="scheiss qt"]Was ich damit meine ist, dass man die Methoden aus fertigen Klassen nicht kopieren kann wegen den ganzen Q_Q(...) und so ein dummes Zeug...

Wenn ich ein Event aus irgendein Widget neuimplementiere, dann gehen die ihre ursprüngliche Funktion nicht mehr weil es sich nicht mit copy&paste identisch kopieren lässt.....[/quote]

Du _kopierst_ den Code der Basisklasse, wenn Du was neuimplementierst und die Basisfunktionalitaet auch haben willst?

Warum rufst in Deiner Neuimplementation nicht einfach die Implementation der Basisklasse auf?

Qt nimmt einem vieles ab, aber ein bisschen C++ braucht man schon.

Abgesehen davon gibt es Eventfilter. Teuer, erlauben aber ohne jegliches Modifikation der Widgets auf Events zu reagieren, sie "anders" zu bearbeiten oder zu ignorieren.

also bitte... benutz visualstudio und .net. fertig. Alles andere is geknaubt und unprofessionell.

Scorcher24

Ich kann mich mit QT auch nicht anfreunden. Oft probiert.
Aber der Metakompiler und diese aufgezwungene Projekt-Datei machen das ganze für mich uninteressant. Ist mir zu viel rumgemurkse.
Ich hab letztens erst probiert einen Sizer so einzubauen im Editor, dass er mit dem Fenster wächst. War mir nicht möglich. Mag an meiner Unkenntniss liegen, aber wxWidgets ist da deutlich einfacher und intuitiver gestrikt.

Scorcher24 schrieb:

Ich hab letztens erst probiert einen Sizer so einzubauen im Editor, dass er mit dem Fenster wächst. War mir nicht möglich. Mag an meiner Unkenntniss liegen...

Ja, daran wirds liegen
Für sowas gibts layout, welche in Qt gut umgesetzt sind.

Scorcher24 schrieb:

... und diese aufgezwungene Projekt-Datei machen das ganze für mich uninteressant.

Das ist doch gerade der Clou, um unabhängig von der IDE eine verständliche Projekt-Datei zu haben, die sich vernünftig in einer Softwareverwaltung pflegen lässt. Damit ist die Softwaregenerierung deutlich nachvollziehbarer, was für Software-Releases ein absolutes muss ist. Ich für meinen Geschmack gehe noch weiter und nutze auch für reine QT-Projekte cmake.