Eine eigene GUI
-
trooper schrieb:
@l'abra d'or
Das wären evtl. Möglichkeiten für QT und nun das ganze für FLTK bitte...
Mit FLTK kommt man da nicht wirklich in Probleme, denn die Lizenz erlaubt statisches Linken, man darf dabei auch den Sourcecode ändern, muss aber die Änderungen unter der LGPL veröffentlichen:
Static linking of applications and widgets to the FLTK library does not constitute a derivative work and does not require the author to provide source code for the application or widget, use the shared FLTK libraries, or link their applications or widgets against a user-supplied version of FLTK.
If you link the application or widget to a modified version of FLTK, then the changes to FLTK must be provided under the terms of the LGPL in sections 1, 2, and 4.
Mit FLTK kenn ich mich aber nicht aus, drum ann ich dir da auch nicht sagen wie es geht.
Sei doch nicht so starrköpfig. Auch mit QT geht nicht alles. QT ist mächtig keine Frage, aber auch da gibt es Grenzen. Genausogut könnte ein Fehler in QT selbst die Ursache sein, dass man den QT Quellcode anfassen muss.
Starrköpfig? Mag sein, allerdings reagiere ich doch nur auf deine (wieder bekräftigte) Aussage, dass es eine Notwendigkeit ist, den Qt-Sourcecode zu verändern. Deine aktuelle Relativierung: Fehler in Qt. -> Bugreport! Patch veröffentlichung. Wenn es ein tatsächlich relevanter Fehler ist, wird der schnell in den Linuxdistributionen eingespielt und im nächsten Patchrelease von Qt enthalten sein.
Aber wenn es dich so stört, dass statisches Linken + Änderungen am Sourcecode von Qt sooo kompliziert ist: Verzichte auf statisches Linken, liefere deine modifizierte Library mit, samt Patches, und sag "Mein Programm funktioniert nur mit diesen und jenen Patches an Qt". Aber irgendwo geht das doch komplett an der Fragestellung vorbei. Ich denke es ist allen klar, worauf man sich bei der LGPL + kommerzielle Nutzung einlässt - man kann seinen Code verheimlichen, muss aber bestimmte Einschränkungen akzeptieren, egal wie sinnvoll diese einem erscheinen.
-
Ich glaube dem Fragesteller war genau das mit den Lizenzen eben nicht klar.
Wer entscheidet denn ob der Fehler relevant ist? Was ist wenn Du zum Beispiel in deinem Projekt eine Designentscheidung treffen musstest, weil vom Kunden so gewünscht, und dann auf den Fehler stößt, der für andere irrelevant erscheint?
Ich schrieb auch nicht dass es eine Notwendigkeit ist, sondern evtl. werden kann, bei evtl. Fehlern, Schwachstellen oder fehlender Funktionalität.
Im Prinzip kann ja jeder selbst entscheiden, was er einsetzen möchte. Wir nehmen aus den Gründen der Lizenz QT genau deshalb eben nicht...
Gruß
Trooper
-
trooper schrieb:
Sei doch nicht so starrköpfig. Auch mit QT geht nicht alles. QT ist mächtig keine Frage, aber auch da gibt es Grenzen. Genausogut könnte ein Fehler in QT selbst die Ursache sein, dass man den QT Quellcode anfassen muss.
Wenn du den Quellcode von QT oder FLTK anfassen musst, dann machst du etwas falsch. Denn dann bindest du dich an diese Version der Library und kannst nicht mehr so einfach updaten.
Das ist nur in absoluten extremen Ausnahmesituationen OK. idR ist es eine dumme Idee.
Und selbst dann ist es ja kein Problem die Quellcode zu veröffentlichen, denn man will ja das die eigenen Patches möglichst schnell in die Offizielle Version übernommen werden
-
Es heißt übrigens Qt und nicht QT.
-
@Tachyon
Aja - noch ein Klugscheißer.@Shade Of Mine
"Wenn du den Quellcode von Qt oder FLTK anfassen musst, dann machst du etwas falsch."Gut, dann machen wir alle hier seit Jahren alles falsch im Team. Wir schreiben hier erfolgreich Visualisierungssoftware für Wissenschaftler. Es ist schon öfters in der Vergangenheit vorgekommen, dass die verwendete GUI nicht das bot was gebaucht wurde - oder der Kunde wollte.
Gut das ihr es alle besser wisst, könnt oder glaubt zu können. Ich glaub was euch fehlt ist ein größeres Projekt und Kunden, die ihre Wünsche auch verwirklicht sehen wollen.
-
trooper schrieb:
Gut das ihr es alle besser wisst, könnt oder glaubt zu können. Ich glaub was euch fehlt ist ein größeres Projekt und Kunden, die ihre Wünsche auch verwirklicht sehen wollen.
Ich glaube du unterschätzt hier einige. Großprojekte sind durchaus den ein oder anderen bekannt (Projekte mit mehreren Millionen Codezeilen, oder Projekte an denen parallel 20 Entwickler [ohne QS... mitzuzählen] arbeiten, halte ich zumindest nicht als Kleinkram).
Und auch in solchen Projekten habe ich noch nie erlebt das im Code der UI-Bibliothek eingegriffen wurden ist, wohl aber (wenn auch sehr, sehr selten) um diese herum eine Ergänzung geschrieben wurden ist. Bei Plattformunabhängigen Projekten ist dies sicherlich problematischer, aber nicht ganz ausgeschlossen.
trooper schrieb:
Aja - noch ein Klugscheißer.
Vielleicht solltest du mal dein Sprachgebrauch etwas ändern.
Lies dir bitte mal deine Posts in aller ruhe und neutral betrachtet durch. Versuch dein Wissen dabei möglichst nicht einfließen zu lassen. Dann kommt dir vielleicht in den Sinn, das einige deiner Aussagen mehr als Missverständlich sind, und mehr Fragen als Antworten liefern.
Das deutet auch eine unnötige Nachfrage des OPs hin, der scheinbar bezüglich der Qt-Lizenz so verwirrt wurde, das er dennoch nochmals nachfragen musste.
Davon abgesehen, das Großprojekte ohnehin das Geld für kommerzielle Lizenzen haben sollten - wenn nicht wird an der falschen Stelle gespart (Alleine wenn man die Lizenzkosten in das Verhältnis zur Arbeitszeit setzt). Und kleine Projekte können in der Regel auch gewisse Abstriche machen. Und wenn man die kommerzielle Lizenz von Qt erwirbt, kann man eben auch die Eingriffe in die UI direkt machen (und über die kommerzielle Lizenz kann man immer noch nachdenken, wenn es wirklich soweit ist).
-
trooper schrieb:
@Tachyon
Aja - noch ein Klugscheißer.Qt == "Cute" - dasToolkit über das wir reden.
QT == QuickTime - Multimedia-Library von Apple für Mac/Win.
Keine Ahnung ob der Hinweis gleich Klugscheißerei ist...@Shade Of Mine
"Wenn du den Quellcode von Qt oder FLTK anfassen musst, dann machst du etwas falsch."Gut, dann machen wir alle hier seit Jahren alles falsch im Team. Wir schreiben hier erfolgreich Visualisierungssoftware für Wissenschaftler. Es ist schon öfters in der Vergangenheit vorgekommen, dass die verwendete GUI nicht das bot was gebaucht wurde - oder der Kunde wollte.
Keine Ahnung ob ihr was falsch macht. Wenn "ihr" (nehme an, das ist ein größeres Team in einer Softwareschmiede) merkt, dass die Lib nicht das bietet, was ihr/eure Kunden sich vorstellen (du hast ja vorher schon gesagt, dass das FLTK ist, oder?), dann solltet ihr das Toolkit wechseln. Wenn selbst so etwas wie Qt, das auch in extrem hochwertigen Programmen eingesetzt wird, nicht reicht und gepatcht werden muss, bleibt nur eins: Kauft euch Lizenzen! Wenn ihr Kunden habt, die eure Software kaufen, dann könnt ihr euch sicher irgendwann eine Lizenz leisten. Falls nicht, solltet ihr darüber nachdenken, die Software unter GPL zu veröffentlichen - ihr könnt ja immer noch den Service "für Kunden kompiliert" + Support verkaufen.
Oder aber ihr schafft es, die Software so zu gestalten, dass ihr ohne Patches auskommt. Denn irgendwann wirds happig. Entweder weil euer Patch nicht mehr angepasst werden kann, oder weil der Kunde die neueste Qt[fltk/...]-Version verwendet, aber eure Software auf den Patch pocht (btw.: habt ihr ne gute Rechtsabteilung?)... Es wird irgendwann krachen
-
asc schrieb:
und über die kommerzielle Lizenz kann man immer noch nachdenken, wenn es wirklich soweit ist
Nein leider nicht.
http://qt.nokia.com/products/licensing/licensing#qt-commercial-licenseThe Qt Commercial Developer License does not allow the incorporation of code developed with the Qt GNU LGPL v. 2.1 or GNU GPL v. 3.0 license versions into a commercial product.
Problem ist halt, dass Lizenzen pro Arbeitsplatz fällig sind. Entwickeln wir mit voller Manpower unter LGPL, dann reduzieren wir, wenn wir fertig sind für reine Bugfixes auf 1-2 Arbeitsplätze und sparen uns hunderttausende an Euro Lizenzgebühren...
Aber die Trolls sind aufgeschlossene Menschen. Du kannst sicher eine eigene Lizenz aushandeln (z.B. LGPL entwickeln (mit allen Einschränkungen) + Support kaufen == billiger als commercial).
-
l'abra d'or schrieb:
asc schrieb:
und über die kommerzielle Lizenz kann man immer noch nachdenken, wenn es wirklich soweit ist
Nein leider nicht...
Gut aber selbst dann muss man nicht seinen eigentlichen Programmcode bei der LGPL-Lizenz veröffentlichen, wenn man an den Qt-Code Anpassungen macht, sondern nur die angepassten Qt-Teile.
LGPL ... The benefit to Qt is that any changes made to Qt must be made available under the terms of this license...
Und wenn es nur um Bugfixe oder kleinere Änderungen/Erweiterungen geht, sehe ich da kaum einen Nachteil.
-
@asc: Ist schon klar, aber das meinte ich jetzt nicht. Du kannst nicht ein Projekt entwickeln, und erst die LGPL-Version der Qt verwenden, und irgendwann sagen "Ey ich brauch Support/Will den QtCode ändern ohne zu veröffentlichen/..., ich kauf mir jetzt ne kommerzielle Lizenz", um mit dieser kommerziellen Lizenz das Projekt weiter zu betreiben/veröffentlichen. Wenn kommerzielle Lizenz, dann musst du dein Projekt komplett neu entwickeln. Und hoffen, dass das schon keiner rausfindet würde ich nicht
-
@l'abra d'or
Nun schreibst Du ja selbst welche Nachteile die Kommerzielle Qt Lizenz mit sich bringt.Änderungen in der GUI sind bei uns auch nicht alltäglich. Wir haben neben den Großprojekten auch viele Kleinaufträge, bei denen sich der Aufwand einfach nicht lohnt.
-
trooper schrieb:
@l'abra d'or
Nun schreibst Du ja selbst welche Nachteile die Kommerzielle Qt Lizenz mit sich bringt.Grotesk... Das ist doch kein Nachteil. Man informiert sich doch, bevor man ein Projekt angeht, ganz speziell wenn das ein größeres ist, an dem viele Menschen dran hängen, und für das man später (viel) Geld verlangt. Dann stolpert man zwangsläufig über diese wichtige Vorbedingung. Dann überlegt man sich, ob die Einschränkungen der LGPL auf Dauer tragbar sind, und entscheidet entsprechend.
Wenn man natürlich denkt, man kann auf diese vorherige Information verzichten, und entscheidet sich blind für die LGPL "Weils cool ist, dass man nix zahlen muss", geschieht es einem nur Recht
Änderungen in der GUI sind bei uns auch nicht alltäglich.
Dann mach es nicht zu einem entscheidenden Kriterium.
-
l'abra d'or schrieb:
Du kannst nicht ein Projekt entwickeln, und erst die LGPL-Version der Qt verwenden, und irgendwann sagen "Ey ich brauch Support/Will den QtCode ändern ohne zu veröffentlichen/..., ich kauf mir jetzt ne kommerzielle Lizenz", um mit dieser kommerziellen Lizenz das Projekt weiter zu betreiben/veröffentlichen.
Dumme Frage, aber wieso ist dies nicht möglich?
-
guenni81 schrieb:
Dumme Frage, aber wieso ist dies nicht möglich?
Schau ein paar Posts weiter oben, da hab ich nen Quote von der Qt-Seite gepostet, samt gemutmaßter Erklärung.
-
@l'abra d'or
So langsam hab ich echt keine Lust mehr.
"Grotesk... Das ist doch kein Nachteil."
Nein!? Für mich schon und zwar ein Gewaltiger."...Man informiert sich doch..."
Haben wir gemacht und uns dagegen entschieden."...und entscheidet sich blind für die LGPL "Weils cool ist, dass man nix zahlen muss", geschieht es einem nur Recht..."
Blind war da gar nichts. Die LGPL ist für eher kleinere Projekte prima geeignet. Vorausgesetzt die GUI kann dabei so bleiben wie sie ist."...Dann mach es nicht zu einem entscheidenden Kriterium..."
Das ist es aber. Vor allem weil man es vorher wissen sollte. Denn später kann es dann um viel Geld gehen.
-
Es sollte mittlerweile jedem klar sein dass unter Verwendung der LGPL
Änderungen am Code von fltk oder Qt veröffentlicht werden müssen
Bei massiven Änderungen dem Kunden die eigene Version von Qt/fltk/... aufgezwungen wird resp. die Patches notwendig werden
dynamisches und statisches Linken (bei Qt mit Einschränkungen) möglich ist
kommerzielle Produkte ohne Veröffentlichung der eigenen Sourcen möglich sind.
beliebig viele Entwickler am Projekt mitarbeiten dürfen
Qt zusätzlich eine kommerzielle Version anbietet, mit viel Support und weitreichenden zusätzlichen Rechten, die du mit fltk nicht hastDer einzige Unterschied zwischen fltk und Qt ist also beim statischen linken zu finden. Wenn es für dich kein Problem ist, die objectfiles zum Neulinken rauszurücken, ist es also bis hierher egal, ob du fltk oder Qt nimmst.
Damit ist klar, dass die Einschränkung "1x LGPL, dann kein commercial mehr möglich" keine entscheidende Einschränkung ist. Vor allem wenns um die Entscheidung "Qt ja oder nein" geht. Da ihr euch gegen Qt entschieden habt, kann das auch kein gravierendes Manko gewesen sein (ihr habt wahrscheinlich eh nix von der Einschränkung gewusst).
Da du auch mit den notwendigen Änderungen keine Ruhe gibst (die du einmal oft, dann doch wieder ganz selten hast), wäre es wirklich mal interessant, welche das sind. Denn prinzipiell kannst du
von der Klasse ableiten, die du anpassen willst
ein eigenes Widget von Grund auf neu schreiben, und dabei von QWidget etvlt. QAbstractScrollArea, oder doch wieder spezialisierter) ableiten.
Durch ausgefuchste Features des Toolkits deine Elemente anpassen (z.B. QStyle, QItemDelegate, Qt Style Sheet, usw.)
Bitte verzeih das Fehlen der Möglichkeiten unter fltk. Ich bin mir sicher, dass es auch hier genügend Möglichkeiten gibt, das Aussehen und Verhalten anzupassen.Dass du keine Lust mehr hast tut mir leid.
Grüßle
-
Bei FLTK ist statisches Linken ausdrücklich erlaubt!
Das ist für mich ein entscheidender Unterschied.Bei dem Rest was Du schreibst merke ich das es bei Dir scheinbar nicht notwendig war in grundlegende Funktionsweisen der GUI einzugreifen. Du beschreibst Standard Herangehensweisen beim gestalten von GUI-Programmen.
Beispiele waren (bei FLTK):
Drucken, FileDialog mit spezialisierter Vorschau, weitere TrueType-Schriftarten, Anpassungen von Fl_Gl_Window usw.
Soll ich noch Weitere aufzählen... ?"...objectfiles zum Neulinken rauszurücken..." klar geht das, hab ich aber noch nie in der Praxis erlebt.
Und bitte dreh mir nicht immer die Worte im Mund herum. Ich schrieb, das es bei uns schon öfter nötig war, aber das heißt noch lange nicht das es auch alltäglich ist.
-
trooper schrieb:
Und bitte dreh mir nicht immer die Worte im Mund herum. Ich schrieb, das es bei uns schon öfter nötig war, aber das heißt noch lange nicht das es auch alltäglich ist.
Erklär mir nur mal warum genau du diese Änderungen nicht in die offizielle Version einfließen lassen willst sondern jedesmal neu Patchen willst.
-
trooper schrieb:
Und bitte dreh mir nicht immer die Worte im Mund herum. Ich schrieb, das es bei uns schon öfter nötig war, aber das heißt noch lange nicht das es auch alltäglich ist.
Erklär mir nur mal warum genau du diese Änderungen nicht in die offizielle Version einfließen lassen willst sondern jedesmal neu Patchen willst.
-
Manche Änderungen hätte man mit Sicherheit in die Offizielle Version mit einfließen lassen sollen. Ich entscheide das ja aber nicht allein.