Qt oder GTK?
-
Ich würde da erstmal überlegen was denn überhaupt deine Anforderungen an die Bibliothek sind. Wenn auf dem Zielsystem auf dem das Programm hinterher laufen soll wenig Speicherplatz vorhanden ist, sollte man vielleicht besser GTK verwenden. QT ist ca 10x so groß wie GTK.
Allerdings handelt es sich bei QT nicht nur um eine reines Grafik-Framework. Es ist eher eine sehr umfassende Werkzeugsammlung, die auch in vielen anderen Bereichen eine große Erleichterung sein kann (Datenbankanbindung, XML-Parser, File-Handling, Druckerzugriff, Socket-Programmierung, Internationalisierung... ).
Das QT die Grundlage für KDE ist, hat keine Auswirkungen. QT-Programme laufen völlig unabhängig vom Windowmanager und benötigt keine KDE-Libs. Genauso könnte
man argumentieren C++ zu verwenden sei unpraktisch, weil es die Grundlage für KDE istDie Portierung nach Windows ist spätestens seit QT4 auch kein Problem mehr. Bis QT3 musste man noch eine teure Lizenz dafür haben, weil es keine Opensource-Version der Windows-Bibliothek gab. Wenn man QT für mehr als nur GUI-Programmierung verwendet (z.B. Netzwerkprogrammierung) macht man sich dort zumindest schonmal nicht von nativen Unix-Bibliotheken abhängig und entwickelte Programme sind relativ schnell portierbar (ob dies immer sinnvoll ist, ist eine andere Frage).
Ich benutze QT für meine Applikationen, muss aber gestehen, dass ich mit GTK wiederum keine Erfahrungen habe.
-
Danke für die Antworten. Ich werde dann bald anfangen Qt zu lernen.
Edit: Kennt aber jemand ein guter Tutorial dafür? Weil ich hab nur die von der trolltech gefunden. Aber leider gibt es den nur in Englisch.
-
Xin schrieb:
Da er noch im ANSI-C Forum postet und nicht im C++ Forum, wäre gtk wohl besser als gtkmm ^^
Öhm, kann man Qt in C programmieren?
-
Hab in ein anderes Forum Tutorials gefunden (für Leute die über google jetzt hierhin kommen
):
[1] http://www.pl-berichte.de/work/qt
[2] http://www.fh-wedel.de/~si/seminare/ws99/Ausarbeitung/kde/kde4.htm#top
[3] http://www.haased.de/linux/qtm_auswahl.html
[4] http://archiv.tu-chemnitz.de/pub/2000/0029/data/
[5] http://groups.google.com/groups?group=de.comp.os.unix.*&as_q=Qt
-
Konrad schrieb:
Xin schrieb:
Da er noch im ANSI-C Forum postet und nicht im C++ Forum, wäre gtk wohl besser als gtkmm ^^
Öhm, kann man Qt in C programmieren?
Um mich mal selber zu zitieren:
Xin schrieb:
bei qt fehlt mir hier die Erfahrung.
Aber so wie mir die Beispielcodes aussehen, würde ich mal auf beste C++ Programmierung setzen und demzufolge auf viele neue Fragen im C++ Forum :->
codetux schrieb:
Das QT die Grundlage für KDE ist, hat keine Auswirkungen. QT-Programme laufen völlig unabhängig vom Windowmanager und benötigt keine KDE-Libs.
Es war schlecht von mir ausgedrückt. Da er unter gnome zu Hause ist, hat gnome oder gtk Programmierung schonmal einen Punkt Vorsprung, da man keine weiteren Libs nachladen müsste, wie es bei kde bzw. qt Programmen notwendig wäre.
Das war eigentlich gemeint.
-
Xin schrieb:
Es war schlecht von mir ausgedrückt. Da er unter gnome zu Hause ist, hat gnome oder gtk Programmierung schonmal einen Punkt Vorsprung, da man keine weiteren Libs nachladen müsste, wie es bei kde bzw. qt Programmen notwendig wäre.
Das war eigentlich gemeint.libs muesste man bei qt4 sowieso nachladen. und qt3 jetzt noch zu lernen hat wenig sinn (außer man wird von der firma her gezwungen. weil zum beispiel ne qt3 lizenz gekauft wurde etc..)
meiner meinung ist das wirklich kein problem. ich als kde'ler wuerde auch nciht davor zurueckschrecken gtk anwendungen zu progn..
mfg aman..
-
Falls du Software machst, die hinterher irgendwie verkauft werden soll:
die Lizenzkosten für Qt sind unverschämt hoch.
Falls du nicht kommerziell (für dich selbst) programmierst, fallen
keine Lizenzkosten an.
-
Was ist denn an den Lizenzkosten von Qt so hoch? Die kann sich jede normale Firma leisten. Wenn nicht -> Laden dicht machen!
Und für Hobby braucht man trotzdem eine Lizenz, wenn man Closedsource macht. Für Hobby auf jeden Fall zu teuer. Nur wer OpenSource macht, braucht bei Qt nichts bezahlen.
Ansonst: mir pers. gefällt GTKmm schon sehr gut. Einziges Manko: es gibt keinen Support für VisualC++ Compiler. Aber die Lib gefällt mir ansonst sehr gut.
-
code-tux schrieb:
Wenn man QT für mehr als nur GUI-Programmierung verwendet (z.B. Netzwerkprogrammierung) macht man sich dort zumindest schonmal nicht von nativen Unix-Bibliotheken abhängig....
Praktisch alle Libs, die unter Linux im GNU-Umfeld entwickelt wurden sind mittlerweile portiert. Meist stehen diese Bibliotheken zudem unter LGPL. Keine Linzenzgebühren, closed source kein Problem.
Was mir an gtkmm besonders gut gefällt: man schreibt einfach echten ANSI C++ Code. STL kann ganz ohne schiefe Tricks genutzt werden (oder ist jetzt bei QT endlich auch soweit?), kein qmake oder irgendwelche anderen proprietären Tools erforderlich.
Leider gibt es in der Tat, was gtkmm angeht, noch Probleme bei der Portierung auf Windows. Ich denke aber, das diese Probleme spätestens Ende des Jahres vergessen sind.
-
e.lienen schrieb:
Praktisch alle Libs, die unter Linux im GNU-Umfeld entwickelt wurden sind mittlerweile portiert. Meist stehen diese Bibliotheken zudem unter LGPL. Keine Linzenzgebühren, closed source kein Problem.
Leider sehe ich sehr viele Libs die der GPL unterliegen. LGPL kommt mir seltener vor. am besten wäre BSD-Lizenz. Letztendlich vertraue ich aber der Boost Community, die bei Netzwerk-Fragen mit der asio einen positiven Schritt getan hat.
e.lienen schrieb:
Was mir an gtkmm besonders gut gefällt: man schreibt einfach echten ANSI C++ Code. STL kann ganz ohne schiefe Tricks genutzt werden (oder ist jetzt bei QT endlich auch soweit?), kein qmake oder irgendwelche anderen proprietären Tools erforderlich.
Genau das gefällt mir an Qt auch nicht: Makros wofür ich noch qmake benötige. Das Argument von Trolltech ist unverständlicherweise immer noch, das es noch nicht genügend ISO-konforme Compiler gibt. Naja, wenn sie meinen...
Bzgl. STL hat Qt wieder sein eigenes Süppchen gekocht, die haben eine QTL oder sowas gebastelt. *brrr*
e.lienen schrieb:
Leider gibt es in der Tat, was gtkmm angeht, noch Probleme bei der Portierung auf Windows. Ich denke aber, das diese Probleme spätestens Ende des Jahres vergessen sind.
Weißt du da mehr als wir? Falls ja, dann würde ich mich über genauere Informationen freuen.
Ich selbst habe sehr oft versucht GTKmm unter Windows und VC++ zum Laufen zu bekommen. No Chance! Jetzt hab ich mir einfach Linux, Gnome und Anjuta installiert um wenigstens GTKmm ausprobieren zu können. Aber es ist nicht das was ich eigentlich will. Eigentlich traurig das ich erstmal Linux installieren muß, um eine portable Lib ausprobieren zu können.
-
aMan schrieb:
meiner meinung ist das wirklich kein problem. ich als kde'ler wuerde auch nciht davor zurueckschrecken gtk anwendungen zu progn..
*grins* Respekt, es gibt sie noch, echte, unerschrockene Männer hinter den Tastaturen ^^
malabarista schrieb:
Falls du Software machst, die hinterher irgendwie verkauft werden soll: die Lizenzkosten für Qt sind unverschämt hoch.
Ich habe mich mal bei Trolltech umgesehen, die wollten für Closed-Source Software erstmal 4000 US$ von mir und das hat mich derart erschreckt, dass das Abenteuer gtk auf KDE zu proggen gar nicht mehr so extrem wirkte. :->
-
Nun ja - ich habe bisher ein paar kleinere Testballons zum Laufen gebracht unter Windows. Das erste (Linker-)Problem trat auf, als ich eine Gtk::TreeView benutzt habe (variable 'vtable for Gtk::TreeViewColumn' can't be auto-imported). Das Problem ist auf der gtkmm-Mailinglist mehrfach aufgetaucht, und der Bug im Bugzilla anhängig. Es gibt aber einige in der List, die das Problem schlicht nicht haben.
Da Gimp und Gtk selbst keinerlei Probleme mehr unter Windows machen und gtkmm im Moment sehr aktiv ist, denke ich, dass das Problem in den nächsten Wochen oder Monaten gelöst ist.
Wenn es Probleme gibt, kann man f. Teile des Programms immer auf Gtk ausweichen.
-
e.lienen schrieb:
Da Gimp und Gtk selbst keinerlei Probleme mehr unter Windows machen und gtkmm im Moment sehr aktiv ist, denke ich, dass das Problem in den nächsten Wochen oder Monaten gelöst ist.
Gtkmm geht oft eigene Wege, im Vergleich zu Gtk+. Ich bin deshalb skeptisch, ob sich die Probleme so schnell in Luft auflösen, wie du behauptest.
Keine Frage, gtkmm ist ne Top-Lib, aber unter Win momentan eher unbrauchbar. Bis es bei mir unter Win läuft, dauert's immer ne knappe Stunde. Was macht da der 0815-Anwender? Kapitulieren. Konkurrenzprogramm nehmen.
Des Weiteren ist die ListView nicht sehr schön gelöst, gleiches gilt für die TreeView. Mit der Kompatiblität von glib zu glibmm hatte es in der letzten Zeit auch ein paar mal gehakt. Man wird sehen. Geil hingegen ist die sigc++, hab noch keine besser Signalhandler lib im Framework-Bereich gesehen.Wenn es Probleme gibt, kann man f. Teile des Programms immer auf Gtk ausweichen.
Keine Gute Idee, Gtk+ und gtkmm zu mischen. Entweder oder.
MfG
GPC
-
e.lienen schrieb:
Nun ja - ich habe bisher ein paar kleinere Testballons zum Laufen gebracht unter Windows. Das erste (Linker-)Problem trat auf, als ich eine Gtk::TreeView benutzt habe (variable 'vtable for Gtk::TreeViewColumn' can't be auto-imported). Das Problem ist auf der gtkmm-Mailinglist mehrfach aufgetaucht, und der Bug im Bugzilla anhängig. Es gibt aber einige in der List, die das Problem schlicht nicht haben.
Da Gimp und Gtk selbst keinerlei Probleme mehr unter Windows machen und gtkmm im Moment sehr aktiv ist, denke ich, dass das Problem in den nächsten Wochen oder Monaten gelöst ist.
Aha? Also am Ende doch nur ein Wunschdenken ohne was konkretes dahinter?! Im ernst, ich hab gedacht da kommt jetzt eine Antwort wie "Es wurde ein zus. GTKmm-Team gegründet das sich speziell mit der Win32-Problematik beschäftigt und zum Jahresende einen idiotensicheren VC++-Port zur Verfügung stellen will." Aber das was du erzählst, gibts tausendfach in jedem Hobbyprojekt. Also wird sich da bis Jahresende sicherlich nichts weltbewegendes tun.
Das Problem ist doch noch nicht mal, das Teile von GTKmm nicht unter Win32 laufen, sondern es fast unmöglich ist das Ding überhaupt zum arbeiten zu bekommen (speziell mit VC++). Ich wäre froh wenn nur Teile nicht laufen würden, weil es heißen würde, das ich es immerhin schon zum Laufen bekommen hätte. Du verstehen?
Die Situation ist doch viel verzwickter, wie GPC sehr deutlich erkannt hat. Das Lib-Design ist im Grunde super, aber der Win32-/Vc++-Support praktisch nicht vorhanden. Schade sage ich da nur!
e.lienen schrieb:
Wenn es Probleme gibt, kann man f. Teile des Programms immer auf Gtk ausweichen.
Naja, das ist sicherlich nicht im Sinne des Erfinders, oder? Laut GTKmm-FAQ wurde die gesamte GTK+ gewrappt und man braucht somit GTK+ nicht mehr direkt ansprechen.
-
Übrigens, würde man versuchen GTKmm in Boost aufnehmen zu lassen, würde es wohl nicht mal zu einem Review kommen. Weil jede Boost Lib auf mind. 2 verschiedenen Compilern laufen muß, um den Anspruch der Portabilität erheben zu können. Das ist aber hier bei GTKmm ja nicht gegeben, da es nur auf GCC läuft. Ist die Frage, ob man GTKmm den Status "portabel" zusprechen kann? (würde man Boosts Ansprüche als Referenz nehmen)
Artchi
PS: Ich weiß, Boost-Aufnahme von GTKmm war hier nie die Rede, ich wollte es nur mal sagen, weil es mir in den Sinn kam.
-
e.lienen schrieb:
(variable 'vtable for Gtk::TreeViewColumn' can't be auto-imported).
Linkerparameter: -Wl,--enable-runtime-pseudo-reloc sollte das Problem eigentlich beheben ...
-
"Was ist denn an den Lizenzkosten von Qt so hoch? Die kann sich jede normale Firma leisten. Wenn nicht -> Laden dicht machen! "
Artchi:tut mir leid, aber ich finde diese Äusserung grosskotzig.
2500 EUR ist einfach unverschämt.
-
malabarista schrieb:
"Was ist denn an den Lizenzkosten von Qt so hoch? Die kann sich jede normale Firma leisten. Wenn nicht -> Laden dicht machen! "
Artchi:tut mir leid, aber ich finde diese Äusserung grosskotzig.
2500 EUR ist einfach unverschämt.
Hmm... nein, finde ich nicht. Das Produkt ist gut, portabel und muss nicht x mal neu lizenziert werden, wenn ich das noch richtig im Kopf habe.
Allerdings war und ist mir 4000, die ich für die Windows und Linux Lizenz hätte zahlen müssen für das Produkt etwas zu teuer. Bei großen Produkten spielen die 4000 wirklich keine Rolle und die Arbeitsleistung, die man durch die Lizenzierung spart, ist grade in D'land unbezahlbar.
Für einen Hobbyprogrammierer sieht die Sache natürlich anders aus.
-
malabarista schrieb:
"Was ist denn an den Lizenzkosten von Qt so hoch? Die kann sich jede normale Firma leisten. Wenn nicht -> Laden dicht machen! "
Artchi:tut mir leid, aber ich finde diese Äusserung grosskotzig.
2500 EUR ist einfach unverschämt.
Nein, das ist nicht großkotzig. Ein einfaches Beispiel: eine Firma mit sagen wir mal 2 Programmierern. Laut c't verdient ein Entwickler ca. 30.000 bis 50.000 EUR pro Jahr (ist nur ein Beispiel!). Macht pro Monat 2500-4166 EUR.
So, wenn eine Firma keine EINMALIGEN 2000 EUR für Qt aufbringen kann, wie will sie dann EINEN von diesen zwei Programmierern den nächsten Monat bezahlen??? Wenn schon alleine eine Qt-Lizenz nicht finanzierbar ist? Dann steht der Laden meiner Meinung nach vor der Pleite.
So, aber wenn die Firma vielleicht diese 2000 EUR (4000 für zwei Programmierer) investiert, kann die Firma im günstigsten Fall Millionen Umsätze, wenn nicht sogar Millionen Gewinne machen. Und das ist das Ziel einer jeden Firma. Und jede Firma muss investieren, ohne Investitionen (und das fängt bei dem Gehalt der Mitarbeiter an) kann man keine Wertschöpfung erreichen.
ALso, ich weiß ja nicht wie du es siehst: aber ich würde lieber 2000 EUR investieren anstatt mich z.B. mit der GTKmm unter Windows abzukrepeln und das Projekt am Ende wegen 2000 EUR scheitert.
Beim Hobby ist es egal, da kann man lustig rumprobieren. Aber in einem Unternehmen?
Ich sage NICHT das die Lizenz für einen Hobby-Entwickler günstig ist. Ganz im Gegenteil, für einen Hobby-Entwickler zu teuer. Aber thats life!
-
Artchi schrieb:
Übrigens, würde man versuchen GTKmm in Boost aufnehmen zu lassen, würde es wohl nicht mal zu einem Review kommen. Weil jede Boost Lib auf mind. 2 verschiedenen Compilern laufen muß, um den Anspruch der Portabilität erheben zu können.
Es läuft mit dem VC++ 7.x, jedenfalls hab ich's vor nem knappen Jahr mal zum Laufen gebracht. Wie's mit dem VC++ 8 aussieht, keine Ahnung, der läuft unter Linux irgendwie nicht
Dennoch hab ich ne Weile gebraucht, bis es mal lief. Es machte keinen Spass. Die imho momentan vernünftigste Variante unter Win ist, den MinGW mit der msys zu nutzen. Das macht keine Probleme, jedenfalls fast keine.
Ist die Frage, ob man GTKmm den Status "portabel" zusprechen kann? (würde man Boosts Ansprüche als Referenz nehmen)
Es ist theoretisch portabel, es hakt an der Praxis.
MfG
GPC