Qt oder GTK?
-
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
-
Wie kommt ihr bloß auf diese Zahlen?
Steht doch auf der Trolltech-Seite was eine Lizenz pro Entwickler kostet, und auch was man für "Maintenance and Support" hinblättern muss...
-
Wieso? Wir haben von 2000 bis 4000 EUR (Xin) geredet. Lag nicht so falsch: 2600 für eine Platform-Lizenz und 4000 für 2 Platformen. Am Ende eh egal, es geht ja nicht um 10.000 EUR Unterschied?
-
Artchi schrieb:
Wieso? Wir haben von 2000 bis 4000 EUR (Xin) geredet. Lag nicht so falsch: 2600 für eine Platform-Lizenz und 4000 für 2 Platformen. Am Ende eh egal, es geht ja nicht um 10.000 EUR Unterschied?
QT erscheint erst sinnvoll, wenn man über mehrere Plattformen entwickeln will. Closed-Source hat unter Linux allein auch nicht wirklich Sinn => mindestens 2 Lizenzen.
-
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!
Naja, was soll das vergleichen von Äpfeln und Birnen. Die Qt-Kosten sind halt die Kosten, die man bezahlt, wenn man sich in Compiler/Linker/Bibliotheken nicht weiter einarbeiten möchte, sondern ein fertiges, simpel funktionierendes Produkt sucht. Versteh' ich ja.
Gtk+ und Gtkmm sind hingegen offen - jeder kann es verbessern, indem er den Entwicklern mitteilt wo es hakt, oder, besser, den Fehler lokalisieren, beheben, und Patches schicken. Das kann unter Umständen einige Stunden Nerven und Arbeit kosten, ja. Die 5260,- EUR* pro Mann (x30 Mitarbeiter = 157.800 EUR) können wesentlich teurer werden, weshalb große z.B. längst auf OpenSource setzen (Erwiterbarkeit/Anpassung sind weitere Gründe). Weshalb sind wohl Gimp, Eclipse, Php, Linux, Apache, gcc und eben auch Gtk so erfolgreich?
Weil es so viele 'Hobbyprogrammierer' gibt, die solche Projekte featuren? Ne, sondern weil insbesondere die großen längst erkannt haben, das es sich lohnt 2 oder 3 Mitarbeiter irgendwo sitzen zu haben, die außer ihren üblichen Aufgaben auch noch fehlende Features in Libs oder IDEs einbauen, die dann, wg. Lizenz, der Community wieder zu Gute kommt.
Und noch was: ich werde meine gtkmm-Sourcen unter Windows zum laufen bringen. So war das bisher immer: die einfachen Sachen laufen überall, will man mal mehr als ein paar Dialoge, dann steht plötzlich doch irgendwo
#ifdef __WIN_32__Ob mit wxWidgets, Gtk+, Qt - selbst mit Java kommen plötzlich Win32-Einschränkungen oder eben Andersartigkeiten zu Tage, an die man nicht im Traum gedacht hätte (Cursor, die nur 16 Pixel groß sein können z.B.). Gibt genug OpenSource Produkte, in deren Quelltext kann man ja mal reinschaun (auch Qt).
* Ja, 5260,- pro Mann - weil Qt mag ja unter Win32 ganz gut sein, aber schau doch mal einer auf wievielen Platformen manche Open Source laufen.
-
Ui, was ist dir denn über die Leber gelaufen? Hab ich hier irgendwo geschrieben das GTK+ oder GTKmm schlecht sind? (ganz im Gegenteil!) Kann das leider nirgends finden. Habe nur geschrieben, das man es nicht so unter Win32 zum Laufen bekommt, wie man es sich von einer portablen Lib wünscht. Und das Recht eine solche Tatsache hier zu nennen, habe ich. (und ich bin nicht der einzige der das sagt, selbst du sagst, das es noch verbessert werden muß) Ich habe schliesslich auch Kritik an Qt geäußert (die Sache mit qmake), bin also nicht parteiisch. Aber dafür hat Qt andere Vorzüge, die GTKmm leider nicht leisten kann.
Es mag ja sein das du Lust und Zeit hast dich mit dem "ans Laufen bekommen" von gtkmm befassen kannst, ich gönns jedem der zu viel Zeit hat. Zeit zu haben ist Luxus! Ich kann dir sagen, das ich diese Zeit nicht habe, und ich deshalb z.B. gtkmm nutzen will, um Anwendungen zu bauen. Ich will meine knappe Zeit nicht mit "gtkmm zum Laufen bekommen" verbringen. Und wenn das nicht in kurzer Zeit läuft, dann ist das Ding für mich auch uninteressant. Was meinste warum es soooo viele MFC-User gibt? (ich gehöre dazu!) Weil man da keinen Handgriff machen muß, damit das ding läuft. Es funktioniert einfach, das ist einer von vielen Kriterien damit ich eine Lib benutze.
Wenn die gtkmm-Freax (und dazu gehörst du ja anscheinend) nicht mehr wollen, das es negative Kritik von der Win32-Fraktion gibt, müsst ihr das ändern. Oder ihr sagt gleich klipp und klar (das wäre ehrlicher!): "Sorry Leute, aber wir wollen keine MS-Compiler unterstützen!". Dann wird sich auch niemand an das Ding ranmachen und somit auch keine Kritik äußern. Weil jeder weiß, was Sache ist. Damit wäre beiden Seiten mehr geholfen.
So wie es zur Zeit ist, ist es einfach ein wischi waschi. Nichts ganzes und nichts halbes. Und sowas kann ich überhaupt nicht ausstehen. Dann soll mir derjennigen reinen Tisch machen.
Trolltech ist wenigsten so ehrlich und die sagen: "wenn ihr wollt, das ihr das Ding unter VC++ benutzen könnt, dann lasst Kohle rüber wachsen."
Das finde ich i.O.
-
e.lienen schrieb:
Weshalb sind wohl Gimp, Eclipse, Php, Linux, Apache, gcc und eben auch Gtk so erfolgreich?
Gimp ist kostenlos, aber bzgl. der Bedienung überarbeitungsfähig.
Eclipse ist für C++ Programmierer bringt C++ Programmierer um den Verstand.
PHP macht selbiges mit PHP-Programmieren, aber dafür ist es ja auch gedacht und weil es für die meisten (inkl. mir) einfacher zu verstehen ist als Perl. Ansonsten ist PHP ein Ding der Unmöglichkeit.
Linux ist Unix-Clone und erfolgreich weil kostenlos, aber nicht weil es als OpenSource den Unix-Gedanken geboren hätte.
Apache ist nicht nur kostenlos, sondern inzwischen in Version 2 vorhanden, davor war die Version 1 erfolgreich und davor war es als A-Patchy-HTTP-Server-Gefrickel im Einsatz. Beim gcc sind wir wieder bei kostenlos.
Das GIMP ToolKit (gtk) war einfach da, weil es gimp gibt und ist wieder kostenlos.
Erfolgreich ist also ein seeehr dehnbarer Vegriff
e.lienen schrieb:
Weil es so viele 'Hobbyprogrammierer' gibt, die solche Projekte featuren? Ne, sondern weil insbesondere die großen längst erkannt haben, das es sich lohnt 2 oder 3 Mitarbeiter irgendwo sitzen zu haben, die außer ihren üblichen Aufgaben auch noch fehlende Features in Libs oder IDEs einbauen, die dann, wg. Lizenz, der Community wieder zu Gute kommt.
Die Großen haben vor allem erkannt, dass es wirtschaftlicher ist, wenn nicht jeder eigene GUI-Libs entwickelt, sondern man diese lizenziert. Ein 10 Personen-Unternehmen kann QT-programmieren und vor der Veröffentlichung eine Lizenz für den einen (1,0) GUI-Programmierer kaufen. Das ist billiger, als die komplette Firma 3 Monate für die GUI-Libs zu beschäftigen.
Eine Weiterentwicklung für gtk+ muss doch nicht der Allgemeinheit zugute kommen, da sich gtk+ doch unter lgpl befindet, oder irre ich mich da?
-
Artchi schrieb:
Wieso? Wir haben von 2000 bis 4000 EUR (Xin) geredet. Lag nicht so falsch: 2600 für eine Platform-Lizenz und 4000 für 2 Platformen. Am Ende eh egal, es geht ja nicht um 10.000 EUR Unterschied?
Naja... Xin hat glaube ich nirgends von 4000 EUR geredet.
Aber es ging eigentlich auch eher darum dass die EINMALIGE Investition gar nicht so einmalig ist wie du behauptest, und dass diese 'einmaligen' Kosten pro Entwickler anfallen.
Von den Beträgen her hast du natürlich recht, das sollte sich eine Firma eigentlich leisten können, stellt sich nur die Frage ob das sinnvoll ist oder nicht.
