4. wxWidgets vs Qt

wxWidgets vs Qt

  • A

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

    0
  • Z

    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.

    0
  • ?

    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...

    0
  • ?

    scheiss qt schrieb:

    ... blablabla ...

    Heulsuse.

    0
  • G

    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

    0
  • L

    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?

    0
  • ?

    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.....

    0
  • ?

    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

    0
  • L

    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.

    0
  • ?

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

    Copy&paste aus basisklassen... 😃

    Also doch ein troll.

    0
  • J

    [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.

    0
  • ?

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

    0
  • S

    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.

    0
  • ?

    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.

    0
  • ?

    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.

    0
  • T

    Scorcher24 schrieb:

    und diese aufgezwungene Projekt-Datei

    Häh? Welche aufgezwungene Projektdatei? Du kannst statt qmake auch CMake nehmen oder eine eigenes Makefile schreiben oder alles von Hand in VS definieren oder, oder ...

    0
  • R

    oder, oder ... das qt VS Addin verwenden ...

    Alle GUI Bibliotheken machen irgendwo nen Spagat zwischen Performance, Usability und Conformität ... Und die GUI bibs unterscheiden sich meist nur welche der Philosophien sie bevorzugen, mit den Konsequenzen in den anderen bereichen.

    Das wegen sollte es fuer einen programmierer nicht DIE GUI-Bibliothek geben, sondern er sollt nach Vorgaben des Projectes die best geeignetste auswaehlen. Und das ist ned einfach 🙂

    Was mir an qt z.b. nicht gefaellt:
    - QBbjecte die automatisch geloescht werden, irgendwann (da kann ich gleich GC's nehmen)
    - Impliziet sharing -> die QT Container verhalten sich nicht 100% vorhersehbar, macht grad in Multithreading Umgebungen aerger.
    - keine versionierungen in den dll namen ... damit werden qt dlls nur lokal problemlos einsetztbar -> jedes programm isntalliert erst mal zig Megabytes mit -> widerspruch zur dll - Philosophie
    - kein 100% statisches linken möglich (also auch die M$ runtimes statisch)

    Trotzdem ist die qt damit noch eine der besseren GUI bibliotheken

    der groesste Vorteil:
    Man baut halt sch.... schnell seine GUI's zusammen.

    Das ganze hat auch nen positiven effekt. Da ich so viel wie möglich qt frei haben will, trenn ich Immer Logic und GUI schicht, und zwar recht sauber ...

    Ciao ...

    0
  • ?

    RHBaum schrieb:

    - QBbjecte die automatisch geloescht werden, irgendwann (da kann ich gleich GC's nehmen)

    QObjects werden nicht irgendwann einfach gelöscht, sondern eindeutig nachvollziehbar.

    RHBaum schrieb:

    - kein 100% statisches linken möglich (also auch die M$ runtimes statisch)

    Also mit mingw ist das definitiv möglich.

    0
  • R

    QObjects werden nicht irgendwann einfach gelöscht, sondern eindeutig nachvollziehbar.

    Theorethisch weisst du es, aber praktisch "solltest" DU das wissen nicht verwenden ! Besonders nich, wenn die Teile mit deleteLater rausgenommen werden.

    Wenn ich den Aufbau eines GC's kenne, kann ich auch vorraussehen, wenn ein Object geloescht wird. Aber auch hier sollte ich das Wissen nicht verwenden ...

    Also mit mingw ist das definitiv möglich.

    Also ich meine nicht Dein Project. Klar, das kannst statisch gegen die QT und statisch gegen die runtime linken. Nur iss das quasi witzlos, weil die statisch gebaute qt immer noch gegen die dynamische runtime linkt.
    DU musst also die statische Qt auch auf die statische runtime verweissen lassen.
    Und da steht in der Doku ausdruecklich, das man das nicht machen sollt 🙂

    Schoen wenn es fuer die mingw geht, fuer den msvc gehts nicht (2005 SP3 + 4.6.4).

    Ciao ...

    0
  • S

    @RHBaum
    Natürlich geht das auch mit dem msvc200xx Compiler. Dazu muss man nur im mkspec folgende Änderung vornehmen:
    original:

    QMAKE_CFLAGS_RELEASE    = -O2 -MD
QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += -O2 -MD -Zi
QMAKE_CFLAGS_DEBUG      = -Zi -MDd

    andern zu:

    QMAKE_CFLAGS_RELEASE    = -O2 -MT
QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += -O2 -MT -Zi
QMAKE_CFLAGS_DEBUG      = -Zi -MTd

    und schon ist das Binary alleine lauffähig auf allen PC's.
    Ich benutze das schon lange so. Das einzige lästige ist, dass man alles selber kompilieren muss 😉

    0
Anmelden zum Antworten