staging.inyokaproject.org

Stalafin schrieb:

Ein interessantes Szenario waere ja ein auf QT basiertes Gnome. ☺

Oh ja, nen rewrite von Gnome, viel Spaß 😀

boom1992 schrieb:

Stalafin schrieb:

Ein interessantes Szenario waere ja ein auf QT basiertes Gnome. ☺

Oh ja, nen rewrite von Gnome, viel Spaß 😀

Hehe, das wird gerade ohnehin schon geplant, das ist Dir klar, oder?

Qt4 und KDE4 haben ne ziemliche Erschuetterung in der Gnome Gemeinde ausgeloest. Waehrend man vor kurzem noch meinte, man braeuchte keine so massive Ueberarbeitung sowohl der Desktopumgebung als auch des Frameworks zu starten, hat man begonnen, das ersthaft in Angriff zu nehmen.

Stellt sich nun die Frage, ob Gnome weiterhin auf GTK+ bzw. auf eine Neu-/Weiterentwicklung setzen wird (das scheint ja gerade im Gespraech zu sein; eine Evolution von GTK+, in welchem nach und nach bestimmte Elemente zuerst als veraltet markiert werden, um sie dann zu entfernen).

Kurzum, ich denke, dass entweder GTK+ in einer Form weiterentwickelt wird, die keinen harten Bruch mit der Vorgaengerversion herbeifuehrt (wie ja zwischen Qt3 und 4 geschehen), oder aber tatsaechlich ein existierendes Framework genutzt wird.

Ein komplett Neues Framework zu bauen, welches essentiell das gleiche tut wie Qt4 finde ich zu abwegig.

Ersteres, Qt ist mitnichten 100% freie Software. Wenn du nämlich mit Qt kommerzielle nicht-freie Software entwickeln möchtest, musst du im Moment immer noch eine Lizenz kaufen. Bei wirklich freier Software steht es dir 100% frei unter welcher weiteren Lizenz du deine Software vertreibst.

Hat Qt mit LGPL nun nicht die gleichen Lizenzbedingungen wie GTK+?

Stalafin schrieb:

boom1992 schrieb:

Stalafin schrieb:

Ein interessantes Szenario waere ja ein auf QT basiertes Gnome. ☺

Oh ja, nen rewrite von Gnome, viel Spaß 😀

Hehe, das wird gerade ohnehin schon geplant, das ist Dir klar, oder?

Ja? Hast du dafür auch ne Quelle?

Qt4 und KDE4 haben ne ziemliche Erschuetterung in der Gnome Gemeinde ausgeloest.

Woran machst du das aus? Ich hab davon nichts gemerkt.

Waehrend man vor kurzem noch meinte, man braeuchte keine so massive Ueberarbeitung sowohl der Desktopumgebung als auch des Frameworks zu starten, hat man begonnen, das ersthaft in Angriff zu nehmen.

Meinst du Gtk+ 3? Ich denke nicht, dass man immer dachte, sowas nie zu entwickeln und nur durch Qt4 umgelenkt wurde.

Stellt sich nun die Frage, ob Gnome weiterhin auf GTK+ bzw. auf eine Neu-/Weiterentwicklung setzen wird (das scheint ja gerade im Gespraech zu sein; eine Evolution von GTK+, in welchem nach und nach bestimmte Elemente zuerst als veraltet markiert werden, um sie dann zu entfernen).

Eine komplette Neuentwicklung wird's nicht: http://live.gnome.org/GTK+/3.0/Tasks

Und Gnome wird natürlich noch auf Gtk+ setzen, wozu sollte Gtk+ 3 denn dann entwickelt werden?

Kurzum, ich denke, dass entweder GTK+ in einer Form weiterentwickelt wird, die keinen harten Bruch mit der Vorgaengerversion herbeifuehrt (wie ja zwischen Qt3 und 4 geschehen), oder aber tatsaechlich ein existierendes Framework genutzt wird.

Letzteres wird nicht passieren. Es gibt einfach kein vergleichbares Toolkit wie Gtk+. Qt4 setzt auf C++ und scheidet deswegen aus. Gobject wird man nicht aufgeben, vor allem, da die Programmiersprachen Vala nicht zum Spaß entwickelt wurde. Bei reinem C wird man sicher nicht bleiben (was ja jetzt schon immer weniger von GNOME eingesetzt wird), aber auf das Qt-C++ auch nicht umsteigen.

Ein komplett Neues Framework zu bauen, welches essentiell das gleiche tut wie Qt4 finde ich zu abwegig.

Wird auch nicht passieren, da man bei Gtk+ bleiben wird.

Bauer schrieb:

Hat Qt mit LGPL nun nicht die gleichen Lizenzbedingungen wie GTK+?

Erst ab der noch nicht erschienenen Version 4.5.

opu.e schrieb:

Weshalb ich darauf komme: in letzter Zeit bemerke ich bei immer mehr Programmen, dass auf Qt gesetzt wird, vor allem von kommerziellen Anbietern. Da wären, Skype, LastFM Player, Virtual Box, VLC. Ich weiß, bis auf VLC setzen diese schon immer Qt ein. Aber mir sind leider gerade nur die eingefallen. Auf jeden Fall fühle ich so einen Trend hin zu Qt, wenn es für beide Desktops sein soll, oder es kommerziell ist.

Bei kommerziellen Anbietern war Qt schon immer beliebt, weil man sich durch eine kommerzielle Trolltech-Lizenz von den Verpflichtungen der GPL freikaufen konnte. Gtk+ war zwar schon immer LGPL und damit theoretisch für kommerzielle Software weniger problematisch, aber wer generell keine Lust hat, nach den Regeln freier Software zu spielen, kauft sich eben eine Qt-Lizenz.

Mit der Mozilla-Familie und OpenOffice.org setzen jedenfalls einige gewichtige "desktop-übergreifende" Software-Projekte auf Gtk+, so dass ich ein drohendes Aussterben des einen oder anderen Toolkits nicht sehen kann.

glasen schrieb:

Qt ist freie Software und gehört niemanden.

Ersteres, Qt ist mitnichten 100% freie Software.

Wenn man einen Begriff wie "freie Software" verwendet, dann sollte man sich schon darüber klar sein, was er bedeutet. Qt fällt spätestens seit dem Release unter der GPL unter die Free Software Definition der FSF, also ist es freie Software.

Und auch sonst kannst Du Dein Anti-Qt-Getrolle stecken lassen. Welche Anwendungen mit PyQt, QtRuby oder Qt Jambi entwickelt wurden, ist vollkommen unerheblich. Wichtig ist, dass diese Bindings existieren, und Support dafür geleistet wird. Es hindert einen also nichts daran, sie zu nutzen. Dein armseliger Versuch, Riverbank Computing zu diskreditieren ist übrigens das schäbigste, was ich in den letzten Wochen hier gesehen habe; zumal Riverbank Computing offizieller Trolltech-Partner ist.

Übrigens stimmt es nicht, dass OOo Gtk+ benutzt. OOo hat ein eigenes GUI-Framework, die Visual Component Library.

Hello World schrieb:

Dein armseliger Versuch, Riverbank Computing zu diskreditieren ist übrigens das schäbigste, was ich in den letzten Wochen hier gesehen habe [...]

Achgottchen... 🙄 Manch einer setzt aber eigenartige Maßstäbe an. Wenn das schäbig bzw. DAS schäbigste sein soll, wie würdest Du dann erst 'ne Beleidigung klassifizieren!? Mann kann's echt übertreiben.

Mal abgesehen davon, dass die Nokia-Tochter jetzt Qt Software heißt.

Und auch Firefox ein eigenes Framework hat...

Stalafin schrieb:

Kurzum, ich denke, dass entweder GTK+ in einer Form weiterentwickelt wird, die keinen harten Bruch mit der Vorgaengerversion herbeifuehrt (wie ja zwischen Qt3 und 4 geschehen)

Hallo? Zwischen Qt3 und Qt4 gabs keinen harten Bruch? Der Bruch war sogar sehr gewaltig! Die sind untereinander kein bisschen kompatibel...

Hello World schrieb:

Wenn man einen Begriff wie "freie Software" verwendet, dann sollte man sich schon darüber klar sein, was er bedeutet. Qt fällt spätestens seit dem Release unter der GPL unter die Free Software Definition der FSF, also ist es freie Software.

Ich wollte mit dem "nicht 100%" freie Software ausdrücken, das man für nicht-OSS-Software, welche man mit Qt entwickeln möchte, immer noch eine kommerzielle Lizenz kaufen muss. In dieser Hinsicht ist Gtk+ im Moment noch "freier" als Qt. Das diese Einschränkung mit der Version 4.5 von Qt wegfällt, ist mir übrigens bewusst. Nur im Moment existiert diese Einschränkung noch.

Und auch sonst kannst Du Dein Anti-Qt-Getrolle stecken lassen. Welche Anwendungen mit PyQt, QtRuby oder Qt Jambi entwickelt wurden, ist vollkommen unerheblich. Wichtig ist, dass diese Bindings existieren, und Support dafür geleistet wird. Es hindert einen also nichts daran, sie zu nutzen.

Sorry, falls ich dir in irgendeiner Weise auf dem falschen Fuß erwischt habe. Tatsache ist aber das, obwohl diese Bindings existieren, sie kaum jemand einsetzt.

Dein armseliger Versuch, Riverbank Computing zu diskreditieren ist übrigens das schäbigste, was ich in den letzten Wochen hier gesehen habe; zumal Riverbank Computing offizieller Trolltech-Partner ist.

Mag ja sein, nur ein besonders professionellen Eindruck macht deren Homepage halt nicht.

P.S. :

Ich habe keinen Hass auf Qt. Ich finde Qt eines der besten Multiplattform-Frameworks welches heute zu haben ist, wenn nicht sogar das Beste. Das ändert aber nichts an der Tatsache das andere Sprachen als C++ von den Qt bzw. KDE-Entwicklern nur sehr wenig eingesetzt werden, auch wenn es gute Bindings für die alternativen Sprachen gibt.

glasen schrieb:

Tatsache ist aber das, obwohl diese Bindings existieren, sie kaum jemand einsetzt.

Immer das selbe Argument. Ist es so schwer zu verstehen, dass Qualität != Quantität? Wen interessiert das, in welcher Sprache die meisten Qt Programme geschrieben sind.
Ich hab PyGTK, wxpython, und PyQt ausprobiert und empfand PyQt als am angenehmsten; obwohl man sicher in jedem produktiv Programme schreiben kann. Das einzige, was mich an Qt gestört hat, ist die Lizenz. Das hat sich dann mit Qt 4.5 auch erledigt.

Gruß, Gon

Carnager schrieb:

Hallo? Zwischen Qt3 und Qt4 gabs keinen harten Bruch? Der Bruch war sogar sehr gewaltig! Die sind untereinander kein bisschen kompatibel...

Das ist mit Verlaub Schwachsinn. Die meisten Qt 3-Programme lassen sich mit Qt 4 kompilieren, genau aus diesem Grund beinhaltet Qt 4 die "Qt 3 Compatibility Classes" um weitgehend abwärtskompatibel zu sein. Zudem gibts ein Tool namens qt3to4 mit dem automatisch alte Qt 3-Programme weitgehend automatisch portiert werden können.

Gon schrieb:

Immer das selbe Argument. Ist es so schwer zu verstehen, dass Qualität != Quantität? Wen interessiert das, in welcher Sprache die meisten Qt Programme geschrieben sind.

Im Prinzip ist es natürlich völlig egal in welcher Sprache ein Programm entwickelt wurde. Es ist aber schon auffällig das gerade unter Gtk+ sehr stark die Sprachbindings eingesetzt werden (Egal ob jetzt Python, Perl, Ruby, C# oder was auch immer) und unter Qt eben nicht.

Das einzige, was mich an Qt gestört hat, ist die Lizenz. Das hat sich dann mit Qt 4.5 auch erledigt.

Wahrscheinlich ist das auch der Hauptgrund warum C++ im Moment noch die dominierende Sprache unter Qt ist.

Vegeta schrieb:

Das ist mit Verlaub Schwachsinn. Die meisten Qt 3-Programme lassen sich mit Qt 4 kompilieren, genau aus diesem Grund beinhaltet Qt 4 die "Qt 3 Compatibility Classes" um weitgehend abwärtskompatibel zu sein.

Es geht dabei nicht wirklich um Kompatibilität sondern primär um eine Hilfe beim portieren von Anwendungen auf Qt4, den wie du schon selbst sagst wirklich abwärtskompatibel ist es nicht.