4. Qt vs gtkmm

Qt vs gtkmm

  • A

    Ein zus. Präprozessor ist denke ich auch nicht mal das Ärgernis. In Java z.B. benutze ich auch XDoclet, ist auch ein Präprozessor. Aber den benutze ich freiwillig, weil ich sonst vieles von Hand machen müsste. Weiterhin wird XDoclet hinfällig, wenn ich dafür Java1.5-Annotatios benutze (im Fall von Hibernate). Aber bei Qt ist das Problem, das der Moc ein Zwang ist und vorallem (das ist das schlimmste für mich) das ich nicht weiß was er denn macht. Klar, grob weiß ich es: er erzeugt irgend einen Code. 😃 Im ernst, er ersetzt praktisch C++-Features! 😮 D.h. Trolltech nutzt einfach nicht den ISO-C++ Sprachumfang. Wenn ich einen aktuellen Compiler habe, dann will ich auch, das dieser bitte ausgenutzt wird. So wie das Beispiel mit Java: unter Java 1.4 gabs noch keine Anotations, da nutze man XDoclet. Heute kann Java 1.5 das was XDoclet geleistet hatte, und ich nutze dann kein XDoclet, wenn ich Java 1.5 habe.

    Trolltech verpennt hier meiner Meinung nach C++. Wie lange soll das Argument noch zählen, das angeblich nicht jeder Compiler Templates oder überhaupt ISO-C++ kann? Das gleiche Argument bringt auch das wx-Team: die wollen ganz einfach keine Namespaces, Templates u.ä. einführen, weil angeblich noch nicht jeder Compiler diese Features unterstützt. Wo leben die?

    0
  • M

    Dieses 'moc' ist an sich nicht weiter schlimm - wenn man qmake verdendet. Will man aber ein anderes Build-System verwenden (wie z.B. die autotools oder bjam) hat man ein mehr oder weniger schweres Problem.

    Ich verwende sehr gerne gtkmm. Es hat meiner Meinung nahc die schönste und modernste API. Nur der GTK(mm)-GUI-Designer (glade) ist eher suboptimal. Da hat Qt mit ihrem Designer die Nase vorn.

    Sobald FLTK 2 stable und mature ist, werde ich mir das sicher auch mal näher anschauen. FLUID finde ich etwas seltsam. Es ist offenbar nicht nur ein GUI-Designer; viel mehr kann man damit seine ganzen Sourcen zusammenklicken.

    0
  • A

    Korrekt, Fluid ist nicht einfach nur ein GUI-Designer. Es ist schon eher ein grafischer Sourceeditor für GUI-Programme. Naja, so in etwa formuliert. 😉 Ist auch wirklich am Anfang ungewöhnlich und man muß sich damit wirklich auseinandersetzen. Aber dann scheint Fluid sehr gute Dienste zu leisten.

    0
  • A

    Ich plaediere fuer Qt 😃 😉
    @moc
    Die Kompatibilitaet ist nicht (mehr) der einzige Grund fuer die Verwendung vom moc, siehe hier http://doc.trolltech.com/4.2/templates.html;

    @gtkmm
    Soweit ich weiß, ist gtkmm nur fuer GUI und nicht fuer Netzwerk. Kann man also imo nicht vergleichen..

    Grueße..
    aMan..

    0
  • B

    Artchi schrieb:

    ... wxWidgets wäre auch schon gestorben, wenn es keine nativen Widgets nutzen würde und die liberale Lizenz nicht wäre. Denn das wx-Team weigert sich doch stur eine Modernisierung zu vollziehen.

    Artchi schrieb:

    Trolltech verpennt hier meiner Meinung nach C++. Wie lange soll das Argument noch zählen, das angeblich nicht jeder Compiler Templates oder überhaupt ISO-C++ kann? Das gleiche Argument bringt auch das wx-Team: die wollen ganz einfach keine Namespaces, Templates u.ä. einführen, weil angeblich noch nicht jeder Compiler diese Features unterstützt. Wo leben die?

    Du irrst, die wxWidgets 3.0 (wxTNG, "The Next Generation") ist schon in der Planung: http://www.wxwidgets.org/wiki/index.php/WxWidgets3 (da gibts nur eine grobe Uebersicht, die meisten Diskussionen finden in einer eigenen Mailingliste statt)

    phlox81 schrieb:

    gtkmm ist sicherlich vom Design her das beste, aber unter Windows ist das Standard Theme einfach nur hässlich.

    Nicht nur das, am schlimmsten finde ich die Darstellungs- und sonstigen Fehler, die unter Windows auftreten. Bei X-Chat blockiert ein DCC File Transfer z. B. das Chatfenster, von den Clipping-Fehlern gar nicht zu reden. Gaim funktioniert unter Windows nur mit der GTK-Runtime 2.6, mit der 2.8 aber nicht, .... das sind jetzt zwar GTK+ spezifische Fehler, aber es wuerd mich wundern wenn sie unter gtkmm nicht auftreten wuerden... Kann aber auch sein dass der Fehler hier bei den Entwicklern liegt, die zu faul sind sich fuer Windows-spezifische Bugs zu interessieren.

    0
  • D

    Ponto schrieb:

    Delryn schrieb:

    Hmm ich hab die anderen nie benutzt, bin mit Qt aber recht zufrieden. Einige Dinge sind dort aber buggy und nerven total, wie z.B. ein Widget um große Datenmengen zu loggen oder die QDockWidget unter Linux.

    Aber in der neuen Version gibt es endlich QTrayIcon 👍

    Ein Widget um große Datenmengen zu loggen?

    Dafür gibt es doch QTextEdit mit setTextFormat(Qt::LogText) oder nicht?

    Ansonsten kann ich Qt empfehlen. Mit den anderen hab ich keine praktische Erfahrung.

    Mit QTextEdit geht das nicht, und Qt::LogText gab es auch nur in der 3.x version.

    Versuch mal riesige Datenmengen zu loggen (10.000 bis 30.000 Zeilen pro Minute), da geht QTextEdit in die Knie. Mit QListWidget geht's besser, aber auch da ist schluss wenn man nicht alle paar tausend Einträge mal das Widget leert und in eine Datei streamt.

    Echt schade 😞

    0
  • ?

    Versuch mal riesige Datenmengen zu loggen (10.000 bis 30.000 Zeilen pro Minute)

    das macht schonmal keinen sinn in einer gui

    0
  • P

    s schrieb:

    Versuch mal riesige Datenmengen zu loggen (10.000 bis 30.000 Zeilen pro Minute)

    das macht schonmal keinen sinn in einer gui

    Ich denke schon. Wir haben einen GUI Logviewer für unsere Hauptanwendungen, der auch bei mehreren Millionen von Zeilen pro Lauf nicht schlapp macht. Ist eine Art graphisches less und tail, aber für unsere Zwecke angepasst und damit weit komfortabler als Kommandozeilenwerkzeuge. Das Ding ist aber weder in Qt noch gtkmm geschrieben, sondern in Motif.

    0
  • ?

    moc

    Was ist moc, von dem alle hier reden ???

    0
  • A

    Das ist ein Präprozessor von Trolltech.

    0
  • ?

    Artchi schrieb:

    Das ist ein Präprozessor von Trolltech.

    Thx

    0
  • ?

    Ponto schrieb:

    Ich verstehe die Kritik am moc zum größten Teil überhaupt nicht. Seine Existenz ist ein kleines Ärgernis, das stimmt, aber man hat ja eigentlich nichts mit dem moc zu tun.

    Bei großen Projekten baut man das ins Makefile ein und fertig. Bei kleinen Projekten nimmt man qmake und merkt gar nicht, dass es den moc gibt.

    Problematisch wirds außerdem dann, wenn das alle machen würden. Du willst ja nicht 233 Preprozessoren für eine CPP Datei aufrufen...

    0
  • H

    Versuch mal riesige Datenmengen zu loggen (10.000 bis 30.000 Zeilen pro Minute)
    [...]
    Wir haben einen GUI Logviewer für unsere Hauptanwendungen, der auch bei mehreren Millionen von Zeilen pro Lauf nicht schlapp macht.

    es ist zwar immer sehr schoen, wenn alles was man so braucht schon fertig ist, aber gerade dieses beispiel halte ich fuer einen ausnahmefall.
    man muss sich ja auch mal ueberlegen, wozu eine "gui" gut ist - sicherlich nicht dafuer, dem benutzer mehrere millionen textzeilen gleichzeitig anzuzeigen, damit er sich alle durchlesen kann 😉
    ich halte qt4 fuer ein sehr ausgereiftes system, sofern man eine unterstuetzte plattform (visualc oder gcc) nutzt - insbesondere der support ist vorbildlich (ich nutze die kommerzielle lizenz).

    0
  • T

    ich frag mich, was der sinn dabei ist, 10k (oder meinetwegen auch 30k) zeilen PRO MINUTE anzeigen zu lassen. damits wichtig aussieht? *G das kann man auch in ne datei loggen und die zeitaufwendige ausgabe bei abruf hinterherschieben.

    0
  • U

    aMan schrieb:

    Ich plaediere fuer Qt 😃 😉
    [...]
    @gtkmm
    Soweit ich weiß, ist gtkmm nur fuer GUI und nicht fuer Netzwerk. Kann man also imo nicht vergleichen..

    Ist auch gut so, was soll Netzwerk in einem GUI Toolkit zu suchen haben?
    Mir ist ein GUI Toolkit lieber, welches sich auf das GUI beschraenkt.

    Gruss
    Urs

    0
  • A

    Mir ist ein Toolkit fuer alles lieber. Dann muss ich nicht mit 20 Verschiedenen Bibliotheken arbeiten. Außerdem ist zum Beispiel die QSqlQueryModel Klasse sehr praktisch. So kann ich mit 2 Zeilen Code das Ergebnis eines SQL Query's anzeigen. Wenn die Lib nur fuer Gui ist, ist sowas kaum moeglich.

    0
  • A

    Qt ist doch auch eher ein Anwendungs-Framework und kein reines GUI-Toolkit. Genauso wie wxWidgets und die MFC.

    0
  • U

    aMan schrieb:

    Mir ist ein Toolkit fuer alles lieber. Dann muss ich nicht mit 20 Verschiedenen Bibliotheken arbeiten.

    Ja so sind die Geschmaeker verschieden. 🙂

    Kommte vermutlich auf die Verwendung an.
    Ich arbeite mit verteilten Applikationen,
    so ist es mir recht,
    wenn das GUI-Toolkit sich auf das GUI beschraenkt.
    Fuer die Kommunikation und im Serverbereich setze ich
    andere Bibliotheken ein.
    ACE/TAO, xerces-c und boost reichen aber aus.

    Gruss
    Urs

    0
  • X

    Urs Stotz schrieb:

    aMan schrieb:

    Mir ist ein Toolkit fuer alles lieber. Dann muss ich nicht mit 20 Verschiedenen Bibliotheken arbeiten.

    Ja so sind die Geschmaeker verschieden. 🙂

    Kommte vermutlich auf die Verwendung an.
    Ich arbeite mit verteilten Applikationen,
    so ist es mir recht,
    wenn das GUI-Toolkit sich auf das GUI beschraenkt.
    Fuer die Kommunikation und im Serverbereich setze ich
    andere Bibliotheken ein.
    ACE/TAO, xerces-c und boost reichen aber aus.

    Gruss
    Urs

    einer meinung...

    0
  • A

    Urs Stotz schrieb:

    aMan schrieb:

    Mir ist ein Toolkit fuer alles lieber. Dann muss ich nicht mit 20 Verschiedenen Bibliotheken arbeiten.

    Ja so sind die Geschmaeker verschieden. 🙂

    Kommte vermutlich auf die Verwendung an.
    Ich arbeite mit verteilten Applikationen,
    so ist es mir recht,
    wenn das GUI-Toolkit sich auf das GUI beschraenkt.
    Fuer die Kommunikation und im Serverbereich setze ich
    andere Bibliotheken ein.
    ACE/TAO, xerces-c und boost reichen aber aus.

    Gruss
    Urs

    👍

    Ich mag auch eher "fette" Programme (Opera, KDevelop, Kate..) andere wollen leichte (Firefox, emachs und vi)..

    0
Anmelden zum Antworten