staging.inyokaproject.org

Dann stelle ich meine Frage nochmal hier:

Heißt das jetzt eigentlich auch, dass man damit Programme erstellen kann und für diese Geld verlangen ohne für Qt zu blechen?

kann das Toolkit in der nächsten Version auch unter der LGPL Version 2.1 veröffentlichen, welche es erlaubt, proprietäre Software mit Qt zu schreiben, ohne Lizenzgebühren an Nokia/Qt Software zahlen zu müssen.

Ja, aber nächsten Version (die dann unter LGPL Version 2.1 steht) ... für die bestehende Version von QT wird die Lizenz ja nicht geändert.

ersetze das Wort "aber" durch "ab der" ... 🙄

@1 Ich habe gelesen, dass das nur bei C Code so richtig ist.
Eigentlich ist es ja unter C++ so, dass du sobald du Templates oder inline Code verwendest, streng genommen den Quellcode von deiner Lib änderst, so dass du dann dein Programm auch unter LGPL veröffentlichen müsstest, da es dann Teil der Bibliothek ist (oder!? ..)
Seltsam ist das schon, weil bei gtkmm (auch LGPL) sind auch Makros und Templates dabei und auf der Hompage steht, dass man auch Kommerzielle Apps erstellen kann.
Kennt sich da jemand genauer aus?

Außerdem denke ich, dass die Teile aus QT ausgliedern werden, die bei größeren (..?) Apps wichtig sind, sonst würde sich ja eine kommerzielle Lizenz keinen Sinn machen, oder?

Ich musste gerade lachen 😀 😀 D:D:D:D:D xD

Die neuen Lizenzen helfen uns, noch geilere Applikationen an die User ausliefern zu können.

@BodomBeachTerror:

Ja, du darfst aber nur dynamisch linken und nicht statisch, da der Qt-Code ja offen bleiben muss.

Gnome mit Qt in dem Unterbau anstatt GTK? 😉

Lizenzbedingt sollte das jetzt gehen. Kennt sich jemand mit Qt und GTK, um zu sagen, ob das für Gnome technologisch vorteilhaft wäre oder nicht?

Ist QT besser als gtk (dh. wenn man C++ nimmt gtkmm) und wenn ja warum?

Kenn mich nur mit gtk (C) aus und finde es eigentlich recht gut durchdacht, allerdings braucht man etwas Einarbeitungszeit.

@8: GNOME müsste also alle Anwendungen auf Basis von Qt neuschreiben. Selbst wenn es technologisch vorteilhaft wäre, wäre es sicherlich nicht sinnvoll. Und ich glaube auch nicht, dass es zu Vermischungen kommen würde. Qt ist C++, GTK+ ist C.

@9: Qt ist ein bedeutend mächtigeres Framework als GTK+. Dazu auch noch für mehrere Platformen verfügbar. Aber am Ende muss man halt selbst entscheiden, was einem besser liegt.

@11: Hä, Gtk+ ist genauso für mehrere Plattformen verfügbar.

@10: sollte Gnome mal doch auf GTK 3 portiert werden (Gnome 3), müssten viele Anwendungen auch ziemlich stark umgeschrieben werden. Vielleicht wäre dann besser direkt auf eine (bessere) Plattform zu setzen, nämlich Qt, wenn ja Qt wirklich besser ist... Wie gesagt, technologisch kann ich das gar nicht beurteilen, hab nur gehört Qt soll wohl moderner und besser durchdacht sein, was das auch heißen soll...

Aber stellt Euch das einfach mal vor ☺, es gibt nur eine Plattform, man kann Anwendungen aus beiden Desktopumgebungen nutzen, ohne tausend von anderen Paketen zu installieren, und das wäre nur ein Vorteil von vielen... Ich hätte auch nichts dagegen wenn GTK in beiden Desktops genutzt wird, das ist mir wirklich gleich, nur wie es z.Zt. aussieht, wird Qt stärker weiterentwickelt.

@11 Also zunäschst: Gtk ist praktisch für jede Platform verfügber. Was kann QT, was man mit gtk nicht machen kann? Ich behaupte nicht, dass gtk unbedingt besser sein muss, aber bisher habe ich nichts gefunden, was man mit gtk nicht machen. Wenn man sich eingearbeitet hat und die Benutzerhandbücher liest, merkt man erst wie mächtig das ist und woran die Entwickler alles gedacht haben.

Was an gtk katastrophal ist, ist die Dokumentation (da für viele Funktionen Beispiele fehlen, außerdem fehlt eine Übersicht welche Klasse mit welcher anderen Klasse wie verknüpft ist)

also laut Wikipedia ist Gtk noch nicht nativ nach MacOS portiert worden. Qt fügt sich nativ in die Platform ein. Eine Qt Anwendung sieht unter Windows wie eine Windows Anwendung aus, unter Mac OS wie eine Mac OS und unter Linux halt wie Qt (ab 4.5 unter GNOME auch wie GNOME). Das ist möglich weil Qt die nativen Zeichenroutinen verwendet.

Qt ist bedeutend mehr als "nur" ein Toolkit. Es ist eine komplette Klassenbibliothek die eigentlich alles bietet was man braucht. Also eher zu vergleichen mit Java oder .Net. Braucht also keine Laufzeitumgebung. Man hat Anbindungen an Datenbanken (SQLite ist sogar integriert), ein Multimedia-Framework (Phonon), eine HTML-Rendering-Engine (WebKit), etc. etc. Das alles mit einer einheitlichen Schnittstelle. Der Entwickler braucht sich also nicht in x verschiedene Technologien einarbeiten, sondern eigentlich nur in eine einzige.

Übrigens die Dokumentation von Qt ist die beste, die ich bisher gesehen habe. Alles ist genauestens dokumentiert.

Die Sachen, die du da aufzählst sind in der Gnome Lib enthalten (... und leider nicht alle platformunabhängig). Auf der anderen Seite: Wenn jedes Programm plattformunabhängig gibt, dann hat man keinen Grund mehr zu Linux zu wechseln 😉

Deswegen sollte es nur unter anderen Plattformen unschön und nicht so funktionell sein!

Die Sachen, die du da aufzählst sind in der Gnome Lib enthalten (... und leider nicht alle platformunabhängig).

Was bedeutet, dass man eine Anwendung gegen GNOME Libs bauen muss. Nichts für Desktop Puristen wie mich (jede Anwendung, die gegen GNOME baut, wird nicht installiert) und auch nichts für Drittanbieter. Stell dir vor GoogleEarth würde gegen die kompletten GNOME Libs binden. Dass Qt die ganzen Bereiche anbietet hat natürlich den extremen Vorteil für KDE, dass man im Gegensatz zu GNOME nicht alles neu schreiben muss. Übrigens GNOME wird in Zukunft WebKit verwenden - also nicht alles was ich aufgezählt habe ist in den GNOME Libs 😉

Auf der anderen Seite: Wenn jedes Programm plattformunabhängig gibt, dann hat man keinen Grund mehr zu Linux zu wechseln 😉 Deswegen sollte es nur unter anderen Plattformen unschön und nicht so funktionell sein!

Sorry, aber dieses Argument finde ich lächerlich. Wenn die Software unter Windows scheiße aussieht, dann wechseln sie nicht zu Linux. Wenn man den Leuten aber Anwendungen wie Amarok, Dolphin oder Marble präsentieren kann und dann ihnen eins von Plasma vorschwärmt, dann wechseln sie vielleicht. Außerdem möchte ich meine guten Anwendungen nicht missen, wenn ich mal gezwungen bin unter Windows zu arbeiten.

Ein kleiner Fehler: vor dem Komma in "heute in dem Qt-Labs Blog mitteilte 🇬🇧 , ist" ist ein Leerzeichen.

@17:Als ob du jede KDE-Andwendung ohne die KDE-Bibliotheken bauen könntest.

@19: Beispiel Marble: es gibt sowohl eine reine Qt Variante als auch eine KDE Variante integriert in kdeedu. Also ja es geht.

Sehr begrüssenswert, für neue Projekte ist QT nun die bessere alternative. Ich finde die Lizenzpolitik hat die Verbreitung etwas ausgebremst.

@18: Danke, hab's korrigiert.

Die oben erwähnten (zum Teil wahren, zum Teil angeblichen) Vorzüge von Qt gegenüber GTK+ werfen die Frage nach guten Entwicklungsmodellen auf – denn sie sind zum großen Teil dadurch (mit-)verursacht, dass GTK+ im Gegensatz zu Qt ein Community-Projekt ist, und es keine koordinierende Firma gibt, die das letzte Wort hat.

Das wirft die Frage auf, ob das Firmen-zentrierte (oder zumindest "Benevolent Dictator for Life"-zentrierte, wie z.B. beim Linux Kernel, Perl, Python etc) dem dezentralen Community-Entwicklungsprozeß überlegen ist.

Nur um mal ein paar Beispiele zu nennen:

- Wenn Entwickler nicht zur Dokumentation gezwungen werden, wird auch nur selten welche erstellt.

- Wenn Entscheidungsprozesse mehr oder weniger demokratisch laufen, ist das Projekt nicht gerade entschlußfreudig. Man denke nur, wie lange jetzt bei GTK+ schon über ein Canvas-Widget philosophiert wird.

- Diese Trägheit, wiederum, erzeugt redundante, unoffizielle Projekte. Beispiel: Wie viele unoffizielle, auf GTK+ basierende, Canvas Widgets gibt es? 10? 20?

- Bei vielen Dingen werden nur die ersten 80% implementiert, die Spaß machen, und der Rest rottet so vor sich hin (Beispiel: GTK+ Druckunterstützung)

Ist dieses Bejubeln von Vorzügen eines zentralisierten Entwicklungsmodells von Seiten großer Teile der OSS Gemeinde ein Unterlegenheits-Eingeständnis? Kann es am Ende eine Firma doch besser als die Community?

Ich finde das kann man nicht so verallgemeinern. WxWidgets z.B. ist hat eine hervorragende Dokumentation und wird soweit ich weiss auch nicht von einer Firma entwickelt

Ich denke von beiden Entwicklungsmodellen ein bisschen ist schon das beste. Community brauch es immer (ja auch Qt wäre ohne sie nicht das was es jetzt ist) und eine Person, die den Hut auf hat und das Projekt zusammenhält, kann auch nie schaden.
Es gibt imho auch nicht die Trennlinie und noch nicht mal zwingend einen Gegensatz zwischen Community-Entwicklung und Firmen- und BDfL-Entwicklung. Bei vielen großen Projekten ist immer mehr oder weniger von beiden vorhanden und das ist gut so.

Deshalb freue ich mich auch wie ein Schnitzel, das Qt das Reponsity öffnen will. Das ist imho fast wichtiger als die (auch sehr wichtige) LGPL-Lizenzierung. Das zusammen ist ein Meilenstein für Qt. Da bin ich mir sicher. Wenn jetzt das imho technisch interessanteste Toolkit der FLOOS-Welt in die Communtity geht und gleichzeitig die Lizenzen liberalisiert, ist das kein Schritt ohne Auswirkungen. (Huch, warum bin ich heute so philosophisch? Hab ich ne Glaskugel verschluckt?)

@23: ich glaube Qt ist hier ein schlechtes Beispiel, da Trolltech immer sehr eng mit der KDE Community zusammengearbeitet hat. Viele Qt Entwickler entstammen der KDE Community und Qt hat auch einige KDE Technologien integriert (z.B. Phonon und WebKit (ich betrachte jetzt den Fork als KDE Technologie 😉 )). Außerdem wurden auch bisher bereits Patches von der KDE Community übernommen, was nun aber einfacher werden dürfte.

@26: Warum sollte es ein schlechtes Beispiel sein? Ich schrieb nichts über Zusammenarbeiten, sondern eher über Projektführung. Da geht es eher um so Fragen wie "Wer hat die Entscheidungsgewalt?" oder "Wer kann Druck auf die Entwickler ausüben?". Und da hat ganz klar Qt Software die Hosen an. Patch-Autoren werden auch in Zukunft ihr Copyright abtreten müssen.

Wenn die Antworten auf die obigen Fragen "Niemand" und "Niemand" heisst, treten halt entsprechende Defizite auf. Da geht die Mär von der selbstorganisierenden OSS Community den Bach runter. Eigentlich eine ziemlich traurige Erkenntnis.

Natürlich ist Qt Software daran interessiert, KDE-Entwickler anzuwerben. Die müssen sie nicht mehr einlernen. Sieht bei Imendio oder Openismus auf GTK+ Seite auch nicht anders aus, und hat nichts mit meiner Aussage zu tun.

@27: du hast natürlich Recht, ich hab bei meinem Post zu stark an den Community Aspekt gedacht. Hatte halt im Hinterkopf Entwicklungsmodelle wie Java oder OpenOffice und da passt Qt halt nicht rein.

Aber um mal ein Beispiel zu nennen, wo OSS Community gut funktioniert und auch ohne zentralisierte Stelle vorankommt: KDE

@28: KDE hätte ich jetzt eher als BDfL mit Aaron Seigo an der Spitze angesehen. Aber klar, das sehen viele bestimmt anders. Und auch bei KDE gilt, dass nicht jedes Teilprojekt gleich gut dokumentiert und stabil ist.

Darüber hinaus bestätigen Ausnahmen immer die Regel. Das gilt sogar für die (von mir unwidersprochene) Aussage, Qt sei kompletter und technisch weiter als GTK+. Es gibt durchaus Bereiche, in denen GTK+ technisch die Nase vorn hat. Deswegen ist die Behauptung, Qt sei weiter, trotzdem nicht falsch.

KDE hätte ich jetzt eher als BDfL mit Aaron Seigo an der Spitze angesehen.

Nein nicht wirklich. Höchstens bei Plasma, was halt sein Projekt ist. Wobei er als e.V. Präsident schon ein bißchen KDE als Projekt leiten konnte, aber er gibt ja dieses Jahr den Vorsitz ab.

Qt ist meiner Meinung nach deutk'lich besser als GTK, nd ich finde diesen Schritt sehr gut! Was mir noch fehlt, ist ein schlankes DE, das QT verwendet. KDE(besonders v4) ist mir einfach zu aufgeblasen! Bis ich eins gefunden habe, werde ich bei Gnome bleiben.

Wer eins weiß: Einfach antworten☺

@1:

Heißt das jetzt eigentlich auch, dass man damit Programme erstellen kann und für diese Geld verlangen ohne für Qt zu blechen?

das konntest du vorher auch schon! Die GPL, genauso wie jede andere Freie-Software-Lizenz, erlaubt jede Art des kommerziellen Einsatzes, der kommerziellen Entwicklung und des kommerziellen Vertriebs!

Ich hoffe bei der Nachricht sind ein paar der ewigen Qt-Lizenz-Unken in Feuer aufgegangen 😇