Wenn Anwendung kaum entwickelt werden, da niemand der langfristig produktiv arbeiten will, mit dem versionswahnsinn klar kommt. Nein Danke. Anwendungensentwickler müssen langfristig planen und nicht bei jeder neuen kleinen Versionsänderung ihr Programm neu schreiben müssen!
Die Anpassungen für den Wechsel von 4 auf 5 werden vielleicht gar nicht so groß ausfallen. Aber es werden mal wieder alle Libraries für die Übergangszeit doppelt ausgeliefert werden müssen.
Was sind denn das für Binsenweisheiten?! QT4 ist ja wohl stabil und der Übergang zu QT5 muss eben durch den Entwickler gewährleistet sein. Das ist wieder mal so typisch von "lasst mich mit neuem Zeug in Ruhe" - eine schreckliche Angewohnheit! Wenn alle so denken würden, dann wären wir bei Kernel 0.99.XYZ, weil keiner sich traut die 1.0 daraus zu machen oder noch schlimmer, man müsste Treiber mit veralteten Interfaces versehen oder veraltete Funktionen benutzen, weil keiner was neues und schnelleres implementiert.
> weil keiner was neues und schnelleres implementiert
Neu ja Schneller NEIN
Woi st denn heutige Software schneller Meist nichtmal auf katueller Hardware, geschweige denn wenn man sich ansieht um wieviel aktuelle Hardware schneller ist als noch vor wenigen jahren
Es ist noch nicht sooo lange her dass ein Win2000 Advanced Server auf 192 MB ram samt Domain-Controller gelaufen iost, Coreldraw und Photoshop konnte man auc noch starten und wenn auch nicht rasend schnell aber doch ein linux in VMware installieren
Heute fliegt dir bei 192 Mb RAm sebst der OS-Installer einer "modernen" linux-Distribution um die Ohren - Merke: Nicht alles was neu ist ist automatisch besser und resssourcenschonend Programmieren kann das Geoscks heute so gut wie gar nicht mehr
Tja der preis der billigen rechenkraft, früher war rechenpower halt teurer wie ein programmierer und dementsprechend musste alles hochoptimiert sein. Bei HPC und hoher paralleler arbeit sind heutige programme/Db's etc aber bedeutend schneller.
Meist nichtmal auf katueller Hardware, geschweige denn wenn man sich ansieht um wieviel aktuelle Hardware schneller ist als noch vor wenigen jahren
Genau da liegt ja auch ein weiteres Kernproblem: die Unfähigkeit auf moderner Hardware performanten Code zu schreiben. Das können nicht viele. Und es liegt daran, dass Einsteiger derart versaut werden und gleich mal an Java und .NET randürfen. Also nicht falsch verstehen, ich habe nichts gegen C# / .NET , ganz im Gegenteil. Aber vom Prinzip her sollte man erstmal lernen vernünftig auf einer Multicore-Architektur performante Applikationen zu schreiben, dann kann man sich auch mit dem anderen Zeug befassen.
Bezüglich des OS-Installer gebe ich Dir vollkommen Recht. Das gehört in exakt die gleiche Kategorie, wer lernt vernünftig zu programmieren, der wird auch ressourcenschonender programmieren.
Dann solltest du dich aber nicht über C+-/Qt beschweren. Qt ist ein auch ein super Framework für embedded Programmierung, das braucht nicht viel Leistung/RAM gemessen an seiner Leistung.
Das Problem heutiger Betriebsysteme ist das immer mehr mit Skript- & VM Sprachen gemacht wird. Ein Python-Programm kommt nunmal nie an die Geschwindigkeit und RAM-Verbrauch eines Qt/C++ Programms heran. Wobei das in den meisten Fällen auch nicht weiter relevant ist.
Wenn man je einmal mit Qt C++ Programmiert hat brauch man sowieso keine Skriptsprache mehr, den Qt macht es einem wirklich sehr einfach.
Ist aber alles eine Frage des Anwedungszweckes. Bin selbst auch Qt/C++ Programmierer und habe mir im Zuge eines Uni-Workshops vor kurzen Phyton angeschaut. Gerade für etwas kleineres ist die Kombination Qt/Phyton wirklich verlockend, ein hochoptimiertes Programm könnte man damit wohl aber nicht vernünftig schreiben.
Wobei ich selbst auch Qt/C++ mit Qt-Creator bevorzuge, bleibt man automatisch auch immer Plattformunabhängig, das ist mit Phyton schon schwieriger.
besser QT wird eingestellt. Dann wird es auch KDE nicht mehr geben und damit können sich endlich alle Kräfte auf Gnome/GTK konzentrieren. Das Linux Desktops hinter Windows hinterherhinken liegt einzig an QT/KDE!
Von Extreme Walrus Juice am Di, 10. Juli 2012 um 09:00 #
Man liest ja immer wieder, dass Qt einfacher zu programmieren sein soll als Gtk. Was macht denn an Qt einfacher? Bitte erzähle mir nicht, dass Qt mehr kann, denn das was Qt mehr kann, holt man sich für Gtk-Anwendungen aus anderen Bibliotheken.
In meinen Augen ist die Philosophie von Gtk: Du programmierst ein Projekt mit einer Sprache Deiner Wahl. Brauchst Du eine GUI, kannst du Gtk nehmen. Das gibt es (wahrscheinlich) auch für die Programmiersprache Deiner Wahl. Es gibt noch viele weitere Bibliotheken, die mit Gtk gut zusammen arbeiten.
Die Philosophie von Qt: Wenn Du Qt nimmst, bekommst Du nahezu alles aus einem Guss. Alles passt hervorragend zusammen und ist aufeinander abgestimmt. Du musst aber C++ programmieren.
Qt ist also stärker auf das Endprodukt, alles sieht gleich aus und funktioniert ähnlich ausgelegt. Darüber hinaus ist alles mit der selben Programmiersprache geschrieben - was durchaus ein Vorteil ist. Vieles kann praktischer und einfacher gehandhabt werden.
Gtk gibt dem Programmierer eine größere Auswahl der Programmiersprache. Das belebt zwar den Wildwuchs, holt aber jeden Entwickler bei seinen Fähigkeiten und Vorlieben ab - was ebenfalls positiv ist. Durch die Gnome-Guidelines wird ebenfalls ein konsistentes Erscheinungsbild angestrebt.
Ich sehe also in den beiden Ansätzen jeweils Vor- und Nachteile.
Aber beschreibe mir bitte ERNSTHAFT, was die Vorteile von Qt sein sollen, bzw. was an Gtk so schlecht ist. Bitte keine Polemik, keine Provokation, keine Vorurteile. Mich würde das einmal ECHT interessieren. Ich kenne GTKmm und möchte mir bald Qt bzw. von Qt abgeleitete Frameworks ansehen. Worauf kann ich mich freuen? Was gilt es zu beachten?
Von Extreme Walrus Juice am Di, 10. Juli 2012 um 13:02 #
Ja, die Doku von Qt ist sehr schön. Ich hab diese hier gefunden: http://doc.qt.nokia.com/. Die von Gtk, ist aber nicht so schlecht. Das Gnome-Projekt initiiert ja nicht nur den Gnome-Desktop, sondern sammelt und pflegt auch allerlei Bibliotheken: http://developer.gnome.org/. Es gibt aber nicht nur API-Referenzen, sondern auch Online-Bücher. Meinen Einstieg mit gtkmm habe ich mit Programming with gtkmm 3 gemacht und bin sehr gut damit klar gekommen. Alles weitere holt man sich aus den API-Dokumentationen, die manchmal tatsächlich etwas knapp sind.
Das Problem der GTK API ist meiner Meinung nach grundsätzlicher Natur: C zwingt die Leute zu lächerlich langen Funktionsnamen. Ich meine nur gtk_dialog_set_alternative_button_order_from_array und überhaupt.
Eine "richtige" OOP Sprache hat da schon ihre Vorteile...
Ok, hier ist also einer, der API-Design nicht von der Methodenaufrufssyntax einer bestimmten Programmiersprache trennen kann. Dir ist schon klar, dass wenn du GTK+ über eine andere Programmiersprache verwendest (Vala, Python, JavaScript, C++, ...), die Methoden-Aufrufssyntax eine Andere und Kürzere ist? API-Design ist sowas wie "hier ist die Abstraktion falsch, hier die Objekthierarchie unglücklich, hier die Bezeichnung falsch gewählt, hier werden Verantwortlichkeiten vermischt, ..." nicht "die Methodenaufrufsyntax von C ist länger".
Das würde auf keinen Fall funktionieren. KDE ist ja eher dafür bekannt, dass es mehr Features hat als Gnome. Sollten tatsächlich die KDE-Entwickler irgendwann mal zu Gnome kommen würde das wahrscheinlich über kurz oder lang zum Chaos führen.
Sind beide eh tot, beide werde von Spielkindern kaputt gespielt. Wenn es in Zukunft noch nen Desktop fuer Linux gibt (der nicht nur von drei Sysadmins verwendet wird, sondern von echten Endusern) wird der wohl Android heissen.
Du könntest damit leider recht haben. Ich verstehs auch nicht was beide projekte sich denken, viva E17 und dabei bleib ich, ein DE für admins für benutzer gibts eh nur XFCE (geringer schulungsaufwand, gleichbleibend und simpel)
Ich Schreibe seit 3,5 Jahren ein Programm (70.000 Zeilen) unter QT 4 mit KDevelop3.5. Bin noch lange nicht fertig. Wenn ich aber dann wieder umstellen muss, dann brauche ich eigentlich auch gar nicht mehr weiter schreiben.
Könnte man da nicht mal sagen: So die Lib bleibt jetzt mal 10 Jahre Stabil? Das man auch langfristig was Planen kann?
Nun ja. Qt4 kam 2005. Also sind das ja schon 7 Jahre. Und so schnell wird Qt4 ja auch nicht verschwinden. Das wird sicherlich noch einige Jahre betreut.
Meine Geschichte ist auch schon ein wenig Älter. Vor Jahren hatte ich mal mit xWidgets rumprobiert. Das lag mir aber gar nicht. Dann habe ich mit KDE 3.5 angefangen, 15.000 Zeilen Später habe ich gemerkt das mein Design Schei... war. Also alles in den Papierkorb. Gewartet bis KDE 4.0 Stabil war (Also KDE API 4.3) Und dort am 4.2009 angefangen. Seit März diesen Jahres habe mit ich ein kleines Motivations-Problem. Und wenn ich dann dran denke das alles Irgendwann auf 5.0 umgestellt werden soll Fördert das nicht gerade die Motivation.
Naja bei GTK als oberflächenkit wäre gleiches passiert, mit viel heftigeren auswirkungen. Aber stimmt schon eine Lib hat stabil zu sein, und ansonsten halt wie z.b python 2.6 und 3.0 paralell zu betreuen, finde das konzept von zwei linien eh gut (stabil und alt, neuer und uU nicht ganz so gereift)
Und wer will so ein Programm haben, das auch nach 4 Jahren noch nicht ansatzweise fertig ist? Meine letzte große Anwendung hatte ca 50000 Zeilen Code, 6 Monate Fulltime Entwicklung, danach 1 Jahr lang immer wieder kleine Features und Bugfixes. Mittlerweile ist es seit 4 Jahren bei mehreren Großkunden im Einsatz.
Mich wundert es nicht, dass du Motivationsprobleme hast, solange möchte ich an nix rumspielen ohne mal den Erfolg und das Feedback zu sehen. Ich bin auch in einem großen OSS Projekt tätig, da teilt man sich halt die Aufgaben mit gleichgesinnten, so dass man da auch nicht Jahre an einem halbfertigen Programm rumspielt.
Kindergarten App? Sorry aber eine Einmannshow die 6 Monat programmiert...das kann nichts grosses sein. Lagerverwaltung? Adressbuch mit Access oder von was reden wir?
Wer sagt denn das nur weils jetzt 5 und nicht mehr 4 heisst die ganzen alten Libs nicht mehr verwendete werden können?
Qt Widgets wie auch alle bekannten bisherigen Qt Klassen sind immernoch gleich in Qt 5 vorhanden, nur ist jetzt das Default UI Modul QML. Aber es zwingt dich keiner nach QML zu wechseln.
Und so wie das klingt wirst du vermutlich auch nie fertig. Such dir mindestens einen der dir dabei hilft, auch damit ihr euch gegenseitig motivieren könnt.
Genau hier liegt aber die eigentliche Gefahr für ein Auseinanderbrechen der Qt Community:
Qt/Quick und Qt/Widgets sind derzeit inkompatible Lösungen und die kontroverse Diskussion welcher Pfad sich durchsetzt ist bisher nur ansatzweise beim Anwender angekommen. Letztendlich entfernt sich Qt/Quick von dem was Qt bislang war: ein C++ Framework. Das ist ein Schritt den viele Anwender nicht bereit sind freiwillig mitzugehen - insbesondere weil Qt/Quick derzeit auf dem Desktop nicht viel Spannendes anzubieten hat.
Dass es zu dieser Situation kommt darf und muß man der Qt Entwicklung vorhalten. Offensichtlich haben sie ( unter den Vorgaben von Nokia ) die Vorstellungen der Anwender falsch eingeschätzt bzw. sind zu sehr darauf fixiert Qt auf mobilen Geräte zu etablieren.
Ich denke es wäre besser gewesen das Cross Platform Paradigma von Qt aufzugeben - Oberflächen für den Desktop und die für mobilen Geräte unterscheiden sich einfach - und Qt/Quick als Umgebung für Smartphones bzw. Tablets zu positionieren ohne es gleichzeitig als Zukunft für den Desktop verkaufen zu wollen.
So riskiert man eine massive Verärgerung der Desktop Entwickler nur um in Umgebungen Fuß fassen zu können - auf denen es ohne Nokia vermutlich eh nie was wird.
Spannend wird aber ohnehin wie es mit der Qt Entwicklung weitergeht. Noch wird die Entwicklung von Nokia finanziert, aber wenn das wegfällt ist die Frage wieviele der derzeitigen Leistungsträger noch in der Lage sind sich neben Beruf und Familie in der Freizeit aktiv zu beteiliegen. D.h. man sollte besser erst mal abwarten inwieweit die Entwicklung die Kraft haben wird Qt/Quick zur Reife zu bringen.
Natürlich, Digia bietet Support an und ist damit an den echten Anwendern interessiert, während Nokia das eher egal war, da sie eine Plattform für sich und ihre Billig Handys im Auge hatten.
Ich frage mich: was ist, wenn Microsoft Nokia übernehmen sollte (z.B. zur Aufrüstung des Patent-Arsenals). Wird man sich dann erniedrigen und die Contributor-Agreements eben für Microsoft unterschreiben ("Pakt mit dem Teufel"), oder wird man das Projekt dann unter einem neuen Namen forken?
Qt/Quick und Qt/Widgets sind derzeit inkompatible Lösungen und die kontroverse Diskussion welcher Pfad sich durchsetzt ist bisher nur ansatzweise beim Anwender angekommen.
Ich denke nicht, dass das in irgendeiner weise beim Benutzer ankommen wird. Die "kontroverse Diskussion" wird künstlich von Leuten vom Zaun gebrochen, die aus welchen Gründen auch immer keine weitere Option für UI haben wollen.
Für die meisten Qt verwendenden Entwickler ist das völlig egal, man benutzt jeweils das für den eigenen Bedarf besser zugeschnittene Modul.
Ob das dann QtWidgets oder QtQuick ist bleibt damit die Entscheidung des Programmherstellers, der wiederum die Bedürfnisse seiner Kunden berücksichtigen wird.
Eine Option war Qt/Quick 1, aber mit Qt5 ist das halt nicht so einfach, weil Du dort Widgets und QML/Komponenten nur bedingt mischen kannst. D.h. Du mußt Dich grundsätzlich festlegen auch wenn Du für unterschiedliche Elemente Deiner Oberfläche zu verschiedenen Ergebnissen kommen würdest ( hoffentlich ändert sich das mit Qt 5.1. ).
Was allgemein übersehen wurde ist die Situation der Qt Addon Bibliotheken deren Entwickler vor dem Problem stehen auf die Dualität reagieren zu müssen. Am Ende bedeutet sie vermutlich den Stillstand jeglicher Eigenentwicklung weil man auf lange Zeit damit beschäftigt ist den Status Quo irgendwie auf Qt/Quick zu duplizieren.
Wenn man dagegen die Dualität in der Bibliothek nicht nachvollziehen will, trifft man die Entscheidung - aufgrund der derzeitigen Unverträglichkeiten - für die Anwender mit, ohne die Anwendung und die Präferenzen der beteiligten Entwickler überhaupt zu kennen.
Was allgemein übersehen wurde ist die Situation der Qt Addon Bibliotheken deren Entwickler vor dem Problem stehen auf die Dualität reagieren zu müssen.
Da sehe ich eigentlich kein Problem. Abhängig von der Art des Addons ist es entweder ein Addon zu QtCore, QtWidgets, QtQuick etc.
Ein vorhandenes Widget Addon bleibt ja weiter einsetzbar, das einzige was sich ändert ist, dass eventuell sogar die Möglicheit besteht, Verbesserungen direkt in Qt aufgenommen zu bekommen.
Beide Ansätze (also widget addon und Einpflegen von Verbesserungen direkt in Qt) werden von Leute gemacht, die an KDE Frameworks arbeiten (das dann auch noch Addons zu anderen Qt Modulen bringen wird).
Ich würde davon ausgehen, dass die engagierten Addon Entwickler dem Beispiel von KDE folgen werden und das Resultat noch flexibler einsetzbare Komponenten sein werden.
Die üblichen Qt Addon Bibliotheken sind Qxt und Qwt - die Situation für KDE ist da weniger schwierig, da die Anzahl der KDE Anwendungen überschaubar ist und ein direkter Kontakt zwischen Anwendungs und Bibliotheksentwicklern besteht. Gerade im kommerziellen Umfeld und auf anderen Betriebssystemen ist die Verwendung der KDE Bibliotheken auch nicht wirklich verbreitet.
Um z.B. das Qwt Plot Framework auch Qt/Quick Anwendungen zur Verfügung stellen zu können, muß man den Code erheblich umbauen um ihn Scene Graph kompatibel zu machen. Das geht nicht ohne massive API Änderungen, die dann zu verständlichem Unmut auf Anwenderseite führt - insbesondere bei denen die Qt/Widgets weiter verwenden wollen ( = nahezu alle, da wohl niemand bestehende Applikationen ohne Not auf Qt/Quick umschreibt ).
Klar man kann auch sagen, dass man Qt/Quick einfach ignoriert - aber damit nimmt man allen Anwendungen die Wahlmöglichkeit - z.B. auch allen KDE Anwendungen die Qwt zum Plotten verwenden.
Was ich meinte ist, dass Qt4 Bibiotheken oder Addons nach wie vor so einsetzbar bleiben, wie sie es unter Qt4 sind, dass aber zusätzlich durch die bessere Modularisierung von Qt5 eben auch Zusatzbibliotheken durchaus in einem breiterem Rahmen verfügbar gemacht werden könnten.
Als Beispiel eben die entsprechenden Umgliederung des KDE Framework 5 Projektes, wo Bibliotheken, die im wesentlichen Addons zu verschiedenen Qt Modulen sind, als solche allein gestellt nutzbar gemacht werden.
Klar man kann auch sagen, dass man Qt/Quick einfach ignoriert - aber damit nimmt man allen Anwendungen die Wahlmöglichkeit - z.B. auch allen KDE Anwendungen die Qwt zum Plotten verwenden.
Das sehe ich weniger problematisch. Benutzer von Qwt werden das weiter verwenden können und werden im Normalfall auch nicht ihre Applikation neu umschreiben (u.a. weil für Anwendungen mit Qwt Benutzung vermutlich Widgetbasierte UI einfach passender ist).
Zusätzlich besteht ja auch in QtQuick 2 die Möglichkeit weiter Teile der UI mit QPainter zu erzeugen, bzw in QtWidgets mit OpenGL zu arbeiten.
Bin noch lange nicht fertig. Wenn ich aber dann wieder umstellen muss, dann brauche ich eigentlich auch gar nicht mehr weiter schreiben.
Da brauchst du dir keine all zu großen Befürchtungen machen. Wenn du die üblichen <ClassName> includes verwendest, musst du im wesentlich nur QT += widgets in deiner .pro Datei hinzufügen (weil die Widgets von QtGui nach QtWidgets gewandert sind).
DIe API der Klassen selbst ist praktisch unverändert, u.U. gibt es Methoden, die als "deprecated" markiert sind und wo im Laufe von Qt5 zu einer Umstellung geraten wird. Funktionieren tun sie aber natürlich nach wie vor.
Sollte, Nokia die Qt-Entwicklung komplett einstellen, so reicht es nicht, wenn KDE-Entwickler an Qt weiterentwickeln.
Das Problem ist, dass fast alle KDE-Entwickler unter Linux entwickeln. Und somit läuft auch KDE hauptsächlich auf Linux/Un*x. Auch wenn es immer mal den einen oder anderen gibt, der auch Binaries für MacOSX und Windows zur Verfügung stellt. Das ist aber nur möglich, weil KDE auf Qt aufbaut. Qt stellt den Übergang her, die plattformunabhängige Qt-API in mit den plattformabhängen APIs zu implementieren. Wenn nun aber vor allem KDE-Entwickler an Qt werkeln würden, dann wäre vor allem die Linux-Implementierung von Qt gut. Und die anderen Plattformen würden eher vernachlassigt werden.
Keine Angst, Qt wird nicht nur von KDE verwendet.. Viele Firmen haben ein grosses interesse an Qt, bzw das es weiter entwickelt wird. Gerade im Embedded Bereich ist Qt sehr stark.
Wobei 80% der Entwicklung bisher von Nokia kommt. Qt ist so groß, dass es schwer wäre, für die ganzen Module, die derzeit von Nokia gemaintaint werden, adäquate non-Nokia Maintainer zu finden.
z.B. Elektrobit, eine Tochterfirma von Audi. Obwohl die mittlerweile die Qt-Libs nun auch spezifisch für ihr Programm anpassen. Warum man nicht zum Upstream beiträgt oder das vermeintliche Problem in der eigentlichen Anwendung umschifft verstehe ich nicht. Lieber riskiert man Inkompatibilitäten was zur Folge hat das man neben den orig. Qt-Libs nochmal die angepassten installieren darf.
Digia sollte sich Qt kaufen und weiterentwickeln. Evtl. könnte ja auch die neue Jolla Ltd. bei der Entwicklung mithelfen/mitfinanzieren.
Was Digia dann noch machen müsste (bzw. fertigstellen) währe ein Android und iOS Port, evtl. auch ein Port für Windows Phone und das Windows Tablet Dingbums (falls Microsoft das zulässt). Dann hätte man endlich ein Framework das alle mehr oder weniger verbreiteten Betriebssysteme unterstützt.
Wenn Anwendung kaum entwickelt werden, da niemand der langfristig produktiv arbeiten will, mit dem versionswahnsinn klar kommt. Nein Danke.
Anwendungensentwickler müssen langfristig planen und nicht bei jeder neuen kleinen Versionsänderung ihr Programm neu schreiben müssen!
Die Anpassungen für den Wechsel von 4 auf 5 werden vielleicht gar nicht so groß ausfallen. Aber es werden mal wieder alle Libraries für die Übergangszeit doppelt ausgeliefert werden müssen.
Was sind denn das für Binsenweisheiten?! QT4 ist ja wohl stabil und der Übergang zu QT5 muss eben durch den Entwickler gewährleistet sein. Das ist wieder mal so typisch von "lasst mich mit neuem Zeug in Ruhe" - eine schreckliche Angewohnheit! Wenn alle so denken würden, dann wären wir bei Kernel 0.99.XYZ, weil keiner sich traut die 1.0 daraus zu machen oder noch schlimmer, man müsste Treiber mit veralteten Interfaces versehen oder veraltete Funktionen benutzen, weil keiner was neues und schnelleres implementiert.
> weil keiner was neues und schnelleres implementiert
Neu ja
Schneller NEIN
Woi st denn heutige Software schneller
Meist nichtmal auf katueller Hardware, geschweige denn wenn man sich ansieht
um wieviel aktuelle Hardware schneller ist als noch vor wenigen jahren
Es ist noch nicht sooo lange her dass ein Win2000 Advanced Server auf 192 MB ram samt Domain-Controller gelaufen iost, Coreldraw und Photoshop konnte man auc noch starten und wenn auch nicht rasend schnell aber doch ein linux in VMware installieren
Heute fliegt dir bei 192 Mb RAm sebst der OS-Installer einer "modernen" linux-Distribution um die Ohren - Merke: Nicht alles was neu ist ist automatisch besser und resssourcenschonend Programmieren kann das Geoscks heute so gut wie gar nicht mehr
Tja der preis der billigen rechenkraft, früher war rechenpower halt teurer wie ein programmierer und dementsprechend musste alles hochoptimiert sein. Bei HPC und hoher paralleler arbeit sind heutige programme/Db's etc aber bedeutend schneller.
Genau da liegt ja auch ein weiteres Kernproblem: die Unfähigkeit auf moderner Hardware performanten Code zu schreiben. Das können nicht viele. Und es liegt daran, dass Einsteiger derart versaut werden und gleich mal an Java und .NET randürfen. Also nicht falsch verstehen, ich habe nichts gegen C# / .NET , ganz im Gegenteil. Aber vom Prinzip her sollte man erstmal lernen vernünftig auf einer Multicore-Architektur performante Applikationen zu schreiben, dann kann man sich auch mit dem anderen Zeug befassen.
Bezüglich des OS-Installer gebe ich Dir vollkommen Recht. Das gehört in exakt die gleiche Kategorie, wer lernt vernünftig zu programmieren, der wird auch ressourcenschonender programmieren.
Dann solltest du dich aber nicht über C+-/Qt beschweren.
Qt ist ein auch ein super Framework für embedded Programmierung, das braucht nicht viel Leistung/RAM gemessen an seiner Leistung.
Das Problem heutiger Betriebsysteme ist das immer mehr mit Skript- & VM Sprachen gemacht wird. Ein Python-Programm kommt nunmal nie an die Geschwindigkeit und RAM-Verbrauch eines Qt/C++ Programms heran. Wobei das in den meisten Fällen auch nicht weiter relevant ist.
Wenn man je einmal mit Qt C++ Programmiert hat brauch man sowieso keine Skriptsprache mehr, den Qt macht es einem wirklich sehr einfach.
Ist aber alles eine Frage des Anwedungszweckes. Bin selbst auch Qt/C++ Programmierer und habe mir im Zuge eines Uni-Workshops vor kurzen Phyton angeschaut. Gerade für etwas kleineres ist die Kombination Qt/Phyton wirklich verlockend, ein hochoptimiertes Programm könnte man damit wohl aber nicht vernünftig schreiben.
Wobei ich selbst auch Qt/C++ mit Qt-Creator bevorzuge, bleibt man automatisch auch immer Plattformunabhängig, das ist mit Phyton schon schwieriger.
Warum muss man noch immer alles mögliche für Nokia unterschreiben, wenn man was beitragen will? CONTRIBUTION AGREEMENT
So kann ich nicht ernstnehmen, dass Qt ein von Nokia unabhängiges Projekt werden soll.
"Warum muss man noch immer alles mögliche für Nokia unterschreiben, wenn man was beitragen will?"
Weil Windowsbashing auf Dauer langweilig wird?
Was ist Nokia?
besser QT wird eingestellt. Dann wird es auch KDE nicht mehr geben und damit können sich endlich alle Kräfte auf Gnome/GTK konzentrieren. Das Linux Desktops hinter Windows hinterherhinken liegt einzig an QT/KDE!
*gähn*
Hängematte?
Gnome und GTK könnten in der Tat ein paar fähige Entwickler gebrauchen. GTK ist technisch ja noch irgendwo bei Win 3.11 angesiedelt.
Man liest ja immer wieder, dass Qt einfacher zu programmieren sein soll als Gtk. Was macht denn an Qt einfacher? Bitte erzähle mir nicht, dass Qt mehr kann, denn das was Qt mehr kann, holt man sich für Gtk-Anwendungen aus anderen Bibliotheken.
In meinen Augen ist die Philosophie von Gtk:
Du programmierst ein Projekt mit einer Sprache Deiner Wahl. Brauchst Du eine GUI, kannst du Gtk nehmen. Das gibt es (wahrscheinlich) auch für die Programmiersprache Deiner Wahl. Es gibt noch viele weitere Bibliotheken, die mit Gtk gut zusammen arbeiten.
Die Philosophie von Qt:
Wenn Du Qt nimmst, bekommst Du nahezu alles aus einem Guss. Alles passt hervorragend zusammen und ist aufeinander abgestimmt. Du musst aber C++ programmieren.
Qt ist also stärker auf das Endprodukt, alles sieht gleich aus und funktioniert ähnlich ausgelegt. Darüber hinaus ist alles mit der selben Programmiersprache geschrieben - was durchaus ein Vorteil ist. Vieles kann praktischer und einfacher gehandhabt werden.
Gtk gibt dem Programmierer eine größere Auswahl der Programmiersprache. Das belebt zwar den Wildwuchs, holt aber jeden Entwickler bei seinen Fähigkeiten und Vorlieben ab - was ebenfalls positiv ist. Durch die Gnome-Guidelines wird ebenfalls ein konsistentes Erscheinungsbild angestrebt.
Ich sehe also in den beiden Ansätzen jeweils Vor- und Nachteile.
Aber beschreibe mir bitte ERNSTHAFT, was die Vorteile von Qt sein sollen, bzw. was an Gtk so schlecht ist. Bitte keine Polemik, keine Provokation, keine Vorurteile. Mich würde das einmal ECHT interessieren.
Ich kenne GTKmm und möchte mir bald Qt bzw. von Qt abgeleitete Frameworks ansehen. Worauf kann ich mich freuen? Was gilt es zu beachten?
Gut durchdachte API
Gute Dokumentation
Sofern du keine weiteren Abhängigkeiten hast, sollte dein Programm problemlos auf andere Betriebssysteme und Architekturen portierbar sein.
lg unreal
Nenn mal ein Beispiel, wo die API von GTK+ nicht durchdacht ist. Nenn mal ein Beispiel, wo die Dokumentation. Hier ist der Link.
*Dokumentation nicht gut ist
Ja, die Doku von Qt ist sehr schön. Ich hab diese hier gefunden: http://doc.qt.nokia.com/.
Die von Gtk, ist aber nicht so schlecht. Das Gnome-Projekt initiiert ja nicht nur den Gnome-Desktop, sondern sammelt und pflegt auch allerlei Bibliotheken: http://developer.gnome.org/. Es gibt aber nicht nur API-Referenzen, sondern auch Online-Bücher. Meinen Einstieg mit gtkmm habe ich mit Programming with gtkmm 3 gemacht und bin sehr gut damit klar gekommen. Alles weitere holt man sich aus den API-Dokumentationen, die manchmal tatsächlich etwas knapp sind.
lg
Das Problem der GTK API ist meiner Meinung nach grundsätzlicher Natur: C zwingt die Leute zu lächerlich langen Funktionsnamen. Ich meine nur gtk_dialog_set_alternative_button_order_from_array und überhaupt.
Eine "richtige" OOP Sprache hat da schon ihre Vorteile...
Ok, hier ist also einer, der API-Design nicht von der Methodenaufrufssyntax einer bestimmten Programmiersprache trennen kann. Dir ist schon klar, dass wenn du GTK+ über eine andere Programmiersprache verwendest (Vala, Python, JavaScript, C++, ...), die Methoden-Aufrufssyntax eine Andere und Kürzere ist? API-Design ist sowas wie "hier ist die Abstraktion falsch, hier die Objekthierarchie unglücklich, hier die Bezeichnung falsch gewählt, hier werden Verantwortlichkeiten vermischt, ..." nicht "die Methodenaufrufsyntax von C ist länger".
Verzieh dich Troll, ich bin der wahre Troll.
Du kannst z.B. auch mit python (qt bindings) Oberflächen erzeugen.
Deine Aussage "Du musst aber C++ programmieren." ist daher völlig falsch.
Du scheinst einiges nicht zu wissen
http://en.wikipedia.org/wiki/Qt_%28framework%29#Bindings
Das würde auf keinen Fall funktionieren. KDE ist ja eher dafür bekannt, dass es mehr Features hat als Gnome. Sollten tatsächlich die KDE-Entwickler irgendwann mal zu Gnome kommen würde das wahrscheinlich über kurz oder lang zum Chaos führen.
Sind beide eh tot, beide werde von Spielkindern kaputt gespielt. Wenn es in Zukunft noch nen Desktop fuer Linux gibt (der nicht nur von drei Sysadmins verwendet wird, sondern von echten Endusern) wird der wohl Android heissen.
Du könntest damit leider recht haben. Ich verstehs auch nicht was beide projekte sich denken, viva E17 und dabei bleib ich, ein DE für admins
für benutzer gibts eh nur XFCE (geringer schulungsaufwand, gleichbleibend und simpel)
E17? Die DE die immer hervorstreicht wie Performant sie trotz ihrer ganzen tollen Effekte ist?..
Geil bist du dumm: Verpiss dich zurück ins Heise-Forum.
Deine üble Ausdrucksweise ist nicht besser und macht das Forum ebenfalls kaputt.
Ein locker flockiges Ha Ha Ha von einem KDE User der ersten Stunde.
Gnome entstand doch nur wegen eines Irrtums einiger Ungeduldiger, schon vergessen?
Gut das die meisten Nutzer vom "WELTBESTEN BETRIEBSSYSTEM"
heute mit dem DNS-CHANGER zu tun haben.
Das macht das Internet richtig schnell.
Das könnte öfter sein.
;)
Mir geht das alles zu schnell.
Ich Schreibe seit 3,5 Jahren ein Programm (70.000 Zeilen) unter QT 4 mit KDevelop3.5. Bin noch lange nicht fertig. Wenn ich aber dann wieder umstellen muss, dann brauche ich eigentlich auch gar nicht mehr weiter schreiben.
Könnte man da nicht mal sagen: So die Lib bleibt jetzt mal 10 Jahre Stabil? Das man auch langfristig was Planen kann?
Steinzeit
Nun ja. Qt4 kam 2005. Also sind das ja schon 7 Jahre. Und so schnell wird Qt4 ja auch nicht verschwinden. Das wird sicherlich noch einige Jahre betreut.
Meine Geschichte ist auch schon ein wenig Älter.
Und wenn ich dann dran denke das alles Irgendwann auf 5.0 umgestellt werden soll Fördert das nicht gerade die Motivation.
Vor Jahren hatte ich mal mit xWidgets rumprobiert. Das lag mir aber gar nicht. Dann habe ich mit KDE 3.5 angefangen, 15.000 Zeilen Später habe ich gemerkt das mein Design Schei... war. Also alles in den Papierkorb. Gewartet bis KDE 4.0 Stabil war (Also KDE API 4.3) Und dort am 4.2009 angefangen. Seit März diesen Jahres habe mit ich ein kleines Motivations-Problem.
Steinzeit
Naja bei GTK als oberflächenkit wäre gleiches passiert, mit viel heftigeren auswirkungen. Aber stimmt schon eine Lib hat stabil zu sein, und ansonsten halt wie z.b python 2.6 und 3.0 paralell zu betreuen, finde das konzept von zwei linien eh gut (stabil und alt, neuer und uU nicht ganz so gereift)
Wer so lange an Software arbeitet und versucht, diese stabil und gut geplant umzusetzen, hat in dieser Welt leider eh verkackt, so traurig das ist.
Mit dem planen geb ich dir recht, aber ein projekt stabil umzusetzen sollte möglich sein (ansonsten hast du wohl als softwareentwickler verkackt).
Wenn man aber nur hobbymässig mit Visual basic 6 programmiert bin ich auf gleicher linie wie du.
Und wer will so ein Programm haben, das auch nach 4 Jahren noch nicht ansatzweise fertig ist?
Meine letzte große Anwendung hatte ca 50000 Zeilen Code, 6 Monate Fulltime Entwicklung, danach 1 Jahr lang immer wieder kleine Features und Bugfixes. Mittlerweile ist es seit 4 Jahren bei mehreren Großkunden im Einsatz.
Mich wundert es nicht, dass du Motivationsprobleme hast, solange möchte ich an nix rumspielen ohne mal den Erfolg und das Feedback zu sehen. Ich bin auch in einem großen OSS Projekt tätig, da teilt man sich halt die Aufgaben mit gleichgesinnten, so dass man da auch nicht Jahre an einem halbfertigen Programm rumspielt.
Kindergarten App? Sorry aber eine Einmannshow die 6 Monat programmiert...das kann nichts grosses sein.
Lagerverwaltung? Adressbuch mit Access oder von was reden wir?
Und sorry mit codezeilen kannst abfahren, das hat nichts mit der komplexität eines programms zu tun.
super runtergemacht, tolle leistung!
Wer sagt denn das nur weils jetzt 5 und nicht mehr 4 heisst die ganzen alten Libs nicht mehr verwendete werden können?
Qt Widgets wie auch alle bekannten bisherigen Qt Klassen sind immernoch gleich in Qt 5 vorhanden, nur ist jetzt das Default UI Modul QML. Aber es zwingt dich keiner nach QML zu wechseln.
Und so wie das klingt wirst du vermutlich auch nie fertig. Such dir mindestens einen der dir dabei hilft, auch damit ihr euch gegenseitig motivieren könnt.
Genau hier liegt aber die eigentliche Gefahr für ein Auseinanderbrechen der Qt Community:
Qt/Quick und Qt/Widgets sind derzeit inkompatible Lösungen und die kontroverse Diskussion welcher Pfad sich durchsetzt ist bisher nur ansatzweise beim Anwender angekommen. Letztendlich entfernt sich Qt/Quick von dem was Qt bislang war: ein C++ Framework. Das ist ein Schritt den viele Anwender nicht bereit sind freiwillig mitzugehen - insbesondere weil Qt/Quick derzeit auf dem Desktop nicht viel Spannendes anzubieten hat.
Dass es zu dieser Situation kommt darf und muß man der Qt Entwicklung vorhalten. Offensichtlich haben sie ( unter den Vorgaben von Nokia ) die Vorstellungen der Anwender falsch eingeschätzt bzw. sind zu sehr darauf fixiert Qt auf mobilen Geräte zu etablieren.
Ich denke es wäre besser gewesen das Cross Platform Paradigma von Qt aufzugeben - Oberflächen für den Desktop und die für mobilen Geräte unterscheiden sich einfach - und Qt/Quick als Umgebung für Smartphones bzw. Tablets zu positionieren ohne es gleichzeitig als Zukunft für den Desktop verkaufen zu wollen.
So riskiert man eine massive Verärgerung der Desktop Entwickler nur um in Umgebungen Fuß fassen zu können - auf denen es ohne Nokia vermutlich eh nie was wird.
Spannend wird aber ohnehin wie es mit der Qt Entwicklung weitergeht. Noch wird die Entwicklung von Nokia finanziert, aber wenn das wegfällt ist die Frage wieviele der derzeitigen Leistungsträger noch in der Lage sind sich neben Beruf und Familie in der Freizeit aktiv zu beteiliegen. D.h. man sollte besser erst mal abwarten inwieweit die Entwicklung die Kraft haben wird Qt/Quick zur Reife zu bringen.
Digia scheint hauptsächlich an dem Desktop-Teil interessiert, während Nokia bisher an dem Quick-Teil interessiert war.
Natürlich, Digia bietet Support an und ist damit an den echten Anwendern interessiert, während Nokia das eher egal war, da sie eine Plattform für sich und ihre Billig Handys im Auge hatten.
Ich frage mich: was ist, wenn Microsoft Nokia übernehmen sollte (z.B. zur Aufrüstung des Patent-Arsenals). Wird man sich dann erniedrigen und die Contributor-Agreements eben für Microsoft unterschreiben ("Pakt mit dem Teufel"), oder wird man das Projekt dann unter einem neuen Namen forken?
Ich denke nicht, dass das in irgendeiner weise beim Benutzer ankommen wird.
Die "kontroverse Diskussion" wird künstlich von Leuten vom Zaun gebrochen, die aus welchen Gründen auch immer keine weitere Option für UI haben wollen.
Für die meisten Qt verwendenden Entwickler ist das völlig egal, man benutzt jeweils das für den eigenen Bedarf besser zugeschnittene Modul.
Ob das dann QtWidgets oder QtQuick ist bleibt damit die Entscheidung des Programmherstellers, der wiederum die Bedürfnisse seiner Kunden berücksichtigen wird.
Eine Option war Qt/Quick 1, aber mit Qt5 ist das halt nicht so einfach, weil Du dort Widgets und QML/Komponenten nur bedingt mischen kannst. D.h. Du mußt Dich grundsätzlich festlegen auch wenn Du für unterschiedliche Elemente Deiner Oberfläche zu verschiedenen Ergebnissen kommen würdest ( hoffentlich ändert sich das mit Qt 5.1. ).
Was allgemein übersehen wurde ist die Situation der Qt Addon Bibliotheken deren Entwickler vor dem Problem stehen auf die Dualität reagieren zu müssen. Am Ende bedeutet sie vermutlich den Stillstand jeglicher Eigenentwicklung weil man auf lange Zeit damit beschäftigt ist den Status Quo irgendwie auf Qt/Quick zu duplizieren.
Wenn man dagegen die Dualität in der Bibliothek nicht nachvollziehen will, trifft man die Entscheidung - aufgrund der derzeitigen Unverträglichkeiten - für die Anwender mit, ohne die Anwendung und die Präferenzen der beteiligten Entwickler überhaupt zu kennen.
Da sehe ich eigentlich kein Problem. Abhängig von der Art des Addons ist es entweder ein Addon zu QtCore, QtWidgets, QtQuick etc.
Ein vorhandenes Widget Addon bleibt ja weiter einsetzbar, das einzige was sich ändert ist, dass eventuell sogar die Möglicheit besteht, Verbesserungen direkt in Qt aufgenommen zu bekommen.
Beide Ansätze (also widget addon und Einpflegen von Verbesserungen direkt in Qt) werden von Leute gemacht, die an KDE Frameworks arbeiten (das dann auch noch Addons zu anderen Qt Modulen bringen wird).
Ich würde davon ausgehen, dass die engagierten Addon Entwickler dem Beispiel von KDE folgen werden und das Resultat noch flexibler einsetzbare Komponenten sein werden.
Die üblichen Qt Addon Bibliotheken sind Qxt und Qwt - die Situation für KDE ist da weniger schwierig, da die Anzahl der KDE Anwendungen überschaubar ist und ein direkter Kontakt zwischen Anwendungs und Bibliotheksentwicklern besteht. Gerade im kommerziellen Umfeld und auf anderen Betriebssystemen ist die Verwendung der KDE Bibliotheken auch nicht wirklich verbreitet.
Um z.B. das Qwt Plot Framework auch Qt/Quick Anwendungen zur Verfügung stellen zu können, muß man den Code erheblich umbauen um ihn Scene Graph kompatibel zu machen. Das geht nicht ohne massive API Änderungen, die dann zu verständlichem Unmut auf Anwenderseite führt - insbesondere bei denen die Qt/Widgets weiter verwenden wollen ( = nahezu alle, da wohl niemand bestehende Applikationen ohne Not auf Qt/Quick umschreibt ).
Klar man kann auch sagen, dass man Qt/Quick einfach ignoriert - aber damit nimmt man allen Anwendungen die Wahlmöglichkeit - z.B. auch allen KDE Anwendungen die Qwt zum Plotten verwenden.
Was ich meinte ist, dass Qt4 Bibiotheken oder Addons nach wie vor so einsetzbar bleiben, wie sie es unter Qt4 sind, dass aber zusätzlich durch die bessere Modularisierung von Qt5 eben auch Zusatzbibliotheken durchaus in einem breiterem Rahmen verfügbar gemacht werden könnten.
Als Beispiel eben die entsprechenden Umgliederung des KDE Framework 5 Projektes, wo Bibliotheken, die im wesentlichen Addons zu verschiedenen Qt Modulen sind, als solche allein gestellt nutzbar gemacht werden.
Das sehe ich weniger problematisch. Benutzer von Qwt werden das weiter verwenden können und werden im Normalfall auch nicht ihre Applikation neu umschreiben (u.a. weil für Anwendungen mit Qwt Benutzung vermutlich Widgetbasierte UI einfach passender ist).
Zusätzlich besteht ja auch in QtQuick 2 die Möglichkeit weiter Teile der UI mit QPainter zu erzeugen, bzw in QtWidgets mit OpenGL zu arbeiten.
Da brauchst du dir keine all zu großen Befürchtungen machen. Wenn du die üblichen <ClassName> includes verwendest, musst du im wesentlich nur
QT += widgets
in deiner .pro Datei hinzufügen (weil die Widgets von QtGui nach QtWidgets gewandert sind).
DIe API der Klassen selbst ist praktisch unverändert, u.U. gibt es Methoden, die als "deprecated" markiert sind und wo im Laufe von Qt5 zu einer Umstellung geraten wird. Funktionieren tun sie aber natürlich nach wie vor.
Sollte, Nokia die Qt-Entwicklung komplett einstellen, so reicht es nicht, wenn KDE-Entwickler an Qt weiterentwickeln.
Das Problem ist, dass fast alle KDE-Entwickler unter Linux entwickeln. Und somit läuft auch KDE hauptsächlich auf Linux/Un*x. Auch wenn es immer mal den einen oder anderen gibt, der auch Binaries für MacOSX und Windows zur Verfügung stellt.
Das ist aber nur möglich, weil KDE auf Qt aufbaut. Qt stellt den Übergang her, die plattformunabhängige Qt-API in mit den plattformabhängen APIs zu implementieren.
Wenn nun aber vor allem KDE-Entwickler an Qt werkeln würden, dann wäre vor allem die Linux-Implementierung von Qt gut. Und die anderen Plattformen würden eher vernachlassigt werden.
Grüße
theuserbl
Seh ich genauso. Das sieht man an anderen "Community"-Projekten. Ohne starke Firmen im Hintergrund dümpelt die Entwicklung nur so vor sich hin.
Keine Angst, Qt wird nicht nur von KDE verwendet..
Viele Firmen haben ein grosses interesse an Qt, bzw das es weiter entwickelt wird. Gerade im Embedded Bereich ist Qt sehr stark.
Wobei 80% der Entwicklung bisher von Nokia kommt. Qt ist so groß, dass es schwer wäre, für die ganzen Module, die derzeit von Nokia gemaintaint werden, adäquate non-Nokia Maintainer zu finden.
z.B. Elektrobit, eine Tochterfirma von Audi. Obwohl die mittlerweile die Qt-Libs nun auch spezifisch für ihr Programm anpassen. Warum man nicht zum Upstream beiträgt oder das vermeintliche Problem in der eigentlichen Anwendung umschifft verstehe ich nicht. Lieber riskiert man Inkompatibilitäten was zur Folge hat das man neben den orig. Qt-Libs nochmal die angepassten installieren darf.
Digia sollte sich Qt kaufen und weiterentwickeln. Evtl. könnte ja auch die neue Jolla Ltd. bei der Entwicklung mithelfen/mitfinanzieren.
Was Digia dann noch machen müsste (bzw. fertigstellen) währe ein Android und iOS Port, evtl. auch ein Port für Windows Phone und das Windows Tablet Dingbums (falls Microsoft das zulässt). Dann hätte man endlich ein Framework das alle mehr oder weniger verbreiteten Betriebssysteme unterstützt.