Warum wählt Canonical für die nächste Generation von Unity QT statt GTK?

Question 1

Die Antwort finden Sie auf der Mailingliste und aufMark Shuttleworths Blog. Dieser Blogbeitrag beantwortet die Frage wahrscheinlich am besten:

Als Teil unserer Planung für Natty+1 müssen wir auf der CD etwas Platz für Qt-Bibliotheken finden und wir werden mit Qt entwickelte Anwendungen auf ihre Aufnahme auf der CD und die Standardinstallation von Ubuntu prüfen.

Benutzerfreundlichkeit und effektive Integration sind Schlüsselwerte für unser Benutzererlebnis. Wir legen Wert darauf, dass die von uns ausgewählten Anwendungen miteinander und mit dem Gesamtsystem harmonieren. In der Vergangenheit hat das bedeutet, dass wir Anwendungen, die mit Gtk geschrieben wurden, den Vorzug gegeben haben, da durch die Verwendung desselben Entwickler-Toolkits automatisch eine gewisse Harmonie entsteht. Da OpenOffice und Firefox jedoch von Anfang an dabei waren, ist Gtk eindeutig keine absolute Voraussetzung. Ich argumentiere jetzt, dass es die Werte sind, die wichtig sind, und das Toolkit nur ein Mittel zu diesem Zweck ist. Wir sollten Apps danach bewerten, wie gut sie die Anforderungen erfüllen, und sie nicht aufgrund technischer Entscheidungen des Entwicklers voreingenommen beurteilen.

Bei der Bewertung einer App für die Ubuntu-Standardinstallation sollten wir uns fragen:

ist es kostenlose Software?

ist es das Beste seiner Klasse?

lässt es sich in die Systemeinstellungen und -präferenzen integrieren?

lässt es sich in andere Anwendungen integrieren?

ist es für Personen zugänglich, die keine Maus oder Tastatur verwenden können?

Ist das Erscheinungsbild mit dem Rest des Systems stimmig?

Natürlich hat die Wahl von Qt durch den Entwickler keinen Einfluss auf die ersten beiden. Qt selbst ist seit langem unter der GPL verfügbar und seit kurzem auch unter der LGPL. Und es gibt jede Menge erstklassige Software, die mit Qt geschrieben wurde; es ist ein sehr leistungsfähiges Toolkit.

Systemeinstellungen und -präferenzen sind jedoch schon lange ein Grund für Reibereien zwischen Qt und Gtk. Die Integration mit Systemeinstellungen und -präferenzen ist entscheidend für das Gefühl, dass eine Anwendung zum System „gehört“. Sie beeinflusst die Fähigkeit, diese Anwendung mit denselben Tools zu verwalten, die man auch für alle anderen Anwendungen verwendet, und die Art der Einstellungs- und Präferenzerfahrung, die Benutzer mit der App haben können. Dies war schon immer ein Problem mit Qt-/KDE-Anwendungen unter Ubuntu, da Gtk-Apps alle einen zentral verwaltbaren Präferenzspeicher verwenden und KDE-Apps die Dinge anders handhaben.

Um dieses Problem zu lösen, treibt Canonical die Entwicklung von dconf-Bindings für Qt voran, damit es möglich ist, eine Qt-App zu schreiben, die dasselbe Einstellungsframework wie alles andere in Ubuntu verwendet. Wir haben einen Vertrag mit Ryan Lortie abgeschlossen, der sich offensichtlich sehr gut mit dconf auskennt, und er wird mit einigen Leuten bei Canonical zusammenarbeiten, die Qt für kundenspezifische Entwicklungsarbeiten für Kunden verwendet haben. Wir sind zuversichtlich, dass das Ergebnis für Qt-Entwickler natürlich sein wird und die Semantik und den Stil von dconf vollständig zum Ausdruck bringt.

Das Qt-Team arbeitet schon lange gut mit der breiteren Ubuntu-Community zusammen. Wir haben alle sechs Monate eine großartige Qt-Vertretung bei UDS, das Kubuntu-Team hat viel Erfahrung und Interesse an der Verpackung und Wartung von Qt, und es gibt einen guten technischen Austausch zwischen Qt-Upstream und verschiedenen Teilen der Ubuntu-Community, einschließlich Canonical. Beispielsweise arbeiten die Qt-Leute an der Integration von uTouch.

Ich würde an den offensichtlichen Stellen zwischen „Qt“ und „KDE“ unterscheiden. Eine KDE-App weiß nichts über die dconf-Systemkonfiguration und kann sich daher nicht einfach in den Ubuntu-Desktop integrieren. Wir werden also nicht vorschlagen, dass Amarok in naher Zukunft Banshee ersetzt! Aber ich denke, es ist durchaus plausibel, dass dconf, sobald es über großartige Qt-Bindungen verfügt, von der KDE-Community in Betracht gezogen wird. Es gibt bessere Leute, die diese Diskussion führen können, wenn sie wollen, also werde ich die Idee hier nicht weiter vorantreiben. Sollte eine KDE-App dennoch lernen, zusätzlich zu den Standardmechanismen von KDE dconf zu sprechen, was unkompliziert sein sollte, wäre sie ein Kandidat für die Standardinstallation von Ubuntu.

Die Entscheidung, sich für Qt zu öffnen, ist in keiner Weise eine Kritik an GNOME. Es ist eine Würdigung der Vielfalt und Komplexität freier Software. Diese Werte der Benutzerfreundlichkeit und Integration bleiben gemeinsame Werte mit GNOME und eine hervorragende Grundlage für die Zusammenarbeit mit GNOME-Entwicklern und Projektmitgliedern. Vielleicht wird GNOME selbst Qt annehmen, vielleicht auch nicht, aber wenn ja, wäre unsere Bereitschaft, diesen Weg zu beschreiten, ein Beitrag zur Führung. Es ist viel einfacher, ein lebendiges Ökosystem zu schaffen, wenn man sozusagen ein gewisses Maß an Abweichungen vom kanonischen Weg akzeptiert. Unsere Arbeit am Design konzentriert sich auf GNOME, wobei Einstellungen und Präferenzen der aktuelle Schwerpunkt sind, während wir auf GNOME 3.0 und gtk3 umsteigen.

Natürlich ist dies eine perfekte Gelegenheit für diejenigen, die sich über diese Beziehung lustig machen möchten, dies zu tun, aber meiner Ansicht nach ist das Wichtigste die solide Beziehung, die wir zu Leuten haben, die tatsächlich Anwendungen unter dem GNOME-Banner schreiben. Wir möchten der beste Weg sein, um die harte Arbeit dieser Entwickler freier Software zu erleichtern.Gegenstand, womit wir die beste Art und Weise meinen, um sicherzustellen, dass es jeden Tag einen echten Unterschied im Leben von Millionen von Menschen bewirkt, und die beste Art und Weise, sie mit ihren Benutzern zu verbinden.

Vielen Dank an die netten Leute bei Trolltech (jetzt Nokia), die Qt zu einem großartigen Toolkit gemacht haben. Herzlich willkommen an alle Entwickler, die es verwenden und Teil des Ubuntu-Erlebnisses sein möchten.

Answer

Die Antwort finden Sie auf der Mailingliste und aufMark Shuttleworths Blog. Dieser Blogbeitrag beantwortet die Frage wahrscheinlich am besten:

Als Teil unserer Planung für Natty+1 müssen wir auf der CD etwas Platz für Qt-Bibliotheken finden und wir werden mit Qt entwickelte Anwendungen auf ihre Aufnahme auf der CD und die Standardinstallation von Ubuntu prüfen.

Benutzerfreundlichkeit und effektive Integration sind Schlüsselwerte für unser Benutzererlebnis. Wir legen Wert darauf, dass die von uns ausgewählten Anwendungen miteinander und mit dem Gesamtsystem harmonieren. In der Vergangenheit hat das bedeutet, dass wir Anwendungen, die mit Gtk geschrieben wurden, den Vorzug gegeben haben, da durch die Verwendung desselben Entwickler-Toolkits automatisch eine gewisse Harmonie entsteht. Da OpenOffice und Firefox jedoch von Anfang an dabei waren, ist Gtk eindeutig keine absolute Voraussetzung. Ich argumentiere jetzt, dass es die Werte sind, die wichtig sind, und das Toolkit nur ein Mittel zu diesem Zweck ist. Wir sollten Apps danach bewerten, wie gut sie die Anforderungen erfüllen, und sie nicht aufgrund technischer Entscheidungen des Entwicklers voreingenommen beurteilen.

Bei der Bewertung einer App für die Ubuntu-Standardinstallation sollten wir uns fragen:

ist es kostenlose Software?

ist es das Beste seiner Klasse?

lässt es sich in die Systemeinstellungen und -präferenzen integrieren?

lässt es sich in andere Anwendungen integrieren?

ist es für Personen zugänglich, die keine Maus oder Tastatur verwenden können?

Ist das Erscheinungsbild mit dem Rest des Systems stimmig?

Natürlich hat die Wahl von Qt durch den Entwickler keinen Einfluss auf die ersten beiden. Qt selbst ist seit langem unter der GPL verfügbar und seit kurzem auch unter der LGPL. Und es gibt jede Menge erstklassige Software, die mit Qt geschrieben wurde; es ist ein sehr leistungsfähiges Toolkit.

Systemeinstellungen und -präferenzen sind jedoch schon lange ein Grund für Reibereien zwischen Qt und Gtk. Die Integration mit Systemeinstellungen und -präferenzen ist entscheidend für das Gefühl, dass eine Anwendung zum System „gehört“. Sie beeinflusst die Fähigkeit, diese Anwendung mit denselben Tools zu verwalten, die man auch für alle anderen Anwendungen verwendet, und die Art der Einstellungs- und Präferenzerfahrung, die Benutzer mit der App haben können. Dies war schon immer ein Problem mit Qt-/KDE-Anwendungen unter Ubuntu, da Gtk-Apps alle einen zentral verwaltbaren Präferenzspeicher verwenden und KDE-Apps die Dinge anders handhaben.

Um dieses Problem zu lösen, treibt Canonical die Entwicklung von dconf-Bindings für Qt voran, damit es möglich ist, eine Qt-App zu schreiben, die dasselbe Einstellungsframework wie alles andere in Ubuntu verwendet. Wir haben einen Vertrag mit Ryan Lortie abgeschlossen, der sich offensichtlich sehr gut mit dconf auskennt, und er wird mit einigen Leuten bei Canonical zusammenarbeiten, die Qt für kundenspezifische Entwicklungsarbeiten für Kunden verwendet haben. Wir sind zuversichtlich, dass das Ergebnis für Qt-Entwickler natürlich sein wird und die Semantik und den Stil von dconf vollständig zum Ausdruck bringt.

Das Qt-Team arbeitet schon lange gut mit der breiteren Ubuntu-Community zusammen. Wir haben alle sechs Monate eine großartige Qt-Vertretung bei UDS, das Kubuntu-Team hat viel Erfahrung und Interesse an der Verpackung und Wartung von Qt, und es gibt einen guten technischen Austausch zwischen Qt-Upstream und verschiedenen Teilen der Ubuntu-Community, einschließlich Canonical. Beispielsweise arbeiten die Qt-Leute an der Integration von uTouch.

Ich würde an den offensichtlichen Stellen zwischen „Qt“ und „KDE“ unterscheiden. Eine KDE-App weiß nichts über die dconf-Systemkonfiguration und kann sich daher nicht einfach in den Ubuntu-Desktop integrieren. Wir werden also nicht vorschlagen, dass Amarok in naher Zukunft Banshee ersetzt! Aber ich denke, es ist durchaus plausibel, dass dconf, sobald es über großartige Qt-Bindungen verfügt, von der KDE-Community in Betracht gezogen wird. Es gibt bessere Leute, die diese Diskussion führen können, wenn sie wollen, also werde ich die Idee hier nicht weiter vorantreiben. Sollte eine KDE-App dennoch lernen, zusätzlich zu den Standardmechanismen von KDE dconf zu sprechen, was unkompliziert sein sollte, wäre sie ein Kandidat für die Standardinstallation von Ubuntu.

Die Entscheidung, sich für Qt zu öffnen, ist in keiner Weise eine Kritik an GNOME. Es ist eine Würdigung der Vielfalt und Komplexität freier Software. Diese Werte der Benutzerfreundlichkeit und Integration bleiben gemeinsame Werte mit GNOME und eine hervorragende Grundlage für die Zusammenarbeit mit GNOME-Entwicklern und Projektmitgliedern. Vielleicht wird GNOME selbst Qt annehmen, vielleicht auch nicht, aber wenn ja, wäre unsere Bereitschaft, diesen Weg zu beschreiten, ein Beitrag zur Führung. Es ist viel einfacher, ein lebendiges Ökosystem zu schaffen, wenn man sozusagen ein gewisses Maß an Abweichungen vom kanonischen Weg akzeptiert. Unsere Arbeit am Design konzentriert sich auf GNOME, wobei Einstellungen und Präferenzen der aktuelle Schwerpunkt sind, während wir auf GNOME 3.0 und gtk3 umsteigen.

Natürlich ist dies eine perfekte Gelegenheit für diejenigen, die sich über diese Beziehung lustig machen möchten, dies zu tun, aber meiner Ansicht nach ist das Wichtigste die solide Beziehung, die wir zu Leuten haben, die tatsächlich Anwendungen unter dem GNOME-Banner schreiben. Wir möchten der beste Weg sein, um die harte Arbeit dieser Entwickler freier Software zu erleichtern.Gegenstand, womit wir die beste Art und Weise meinen, um sicherzustellen, dass es jeden Tag einen echten Unterschied im Leben von Millionen von Menschen bewirkt, und die beste Art und Weise, sie mit ihren Benutzern zu verbinden.

Vielen Dank an die netten Leute bei Trolltech (jetzt Nokia), die Qt zu einem großartigen Toolkit gemacht haben. Herzlich willkommen an alle Entwickler, die es verwenden und Teil des Ubuntu-Erlebnisses sein möchten.

Question 2

GTK+ unterstützt keine Auflösungsunabhängigkeit. Moderne Mobilgeräte haben eine extrem hohe Pixeldichte. Wenn Sie eine GTK+-Anwendung auf einem Mobilgerätebildschirm ausführen, wären alle Elemente der Benutzeroberfläche so klein, dass sie unbrauchbar wären.

Dies warein offener Fehler bei GTK+von 2008 bis zur Schließung im Jahr 2014 mit dem Kommentar „Wir haben jetzt Unterstützung für hohe DPI-Skalierung – es ist nicht ganz dasselbe, aber nah genug dran, um diesen Fehler zu beseitigen“.

Als GTK+3 veröffentlicht wurde, bot sich dem Projekt die perfekte Gelegenheit, Auflösungsunabhängigkeit hinzuzufügen, da die Kompatibilität ohnehin beeinträchtigt war. Sie haben sich dagegen entschieden und jetzt ist es wirklich zu spät für sie.

Auf derGTK+-Roadmap, Auflösungsunabhängigkeit ist für die Version nach 4.0 geplant, also werden sie 4.0 veröffentlichen und dann die Hauptversion danach. Wenn sie an diesem Plan festhalten, müssen sogar Desktop-GNU/Linux GTK+ aufgeben, weil hochauflösende Desktop-Monitore und Laptop-Monitore bereits verfügbar sind und bald zum neuen Standard werden.

Answer

GTK+ unterstützt keine Auflösungsunabhängigkeit. Moderne Mobilgeräte haben eine extrem hohe Pixeldichte. Wenn Sie eine GTK+-Anwendung auf einem Mobilgerätebildschirm ausführen, wären alle Elemente der Benutzeroberfläche so klein, dass sie unbrauchbar wären.

Dies warein offener Fehler bei GTK+von 2008 bis zur Schließung im Jahr 2014 mit dem Kommentar „Wir haben jetzt Unterstützung für hohe DPI-Skalierung – es ist nicht ganz dasselbe, aber nah genug dran, um diesen Fehler zu beseitigen“.

Als GTK+3 veröffentlicht wurde, bot sich dem Projekt die perfekte Gelegenheit, Auflösungsunabhängigkeit hinzuzufügen, da die Kompatibilität ohnehin beeinträchtigt war. Sie haben sich dagegen entschieden und jetzt ist es wirklich zu spät für sie.

Auf derGTK+-Roadmap, Auflösungsunabhängigkeit ist für die Version nach 4.0 geplant, also werden sie 4.0 veröffentlichen und dann die Hauptversion danach. Wenn sie an diesem Plan festhalten, müssen sogar Desktop-GNU/Linux GTK+ aufgeben, weil hochauflösende Desktop-Monitore und Laptop-Monitore bereits verfügbar sind und bald zum neuen Standard werden.

Question 3

Technischer Leiter von UbuntuMatt Zimmermans Blogist auch informativ:

In diesem Sinne habe ich in letzter Zeit über Qt nachgedacht. Wir möchten die Entwicklung von Anwendungen für Ubuntu schnell, einfach und unkompliziert machen, und Qt ist für Anwendungsentwickler eine Option, die es wert ist, in Erwägung gezogen zu werden. Als ich darüber nachdachte, wurde mir klar, dass es viele Gemeinsamkeiten zwischen den Stärken von Qt und einigen der neuen Richtungen in Ubuntu gibt:

Qt hat eine lange Geschichte der Nutzung aufARM sowie x86, aufgrund der Beliebtheit auf eingebetteten Geräten. Verbraucherprodukte werden seit über 10 Jahren mit Qt auf ARM entwickelt. Wir stellen Ubuntu-Produkte seit fast zwei Jahren für ARM zur Verfügung und 10.10 unterstützt mehr ARM-Boards als je zuvor, darunter Referenzboards von Freescale, Marvell und TI. Qt fügt ARMv7-Optimierungen hinzu, um die neuesten ARM-Chips zu nutzen. Wir tun dies, um OEMs eine Auswahl an Hardware zu bieten, ohne die Auswahl an Software zu beeinträchtigen. Qt bewahrt diese Auswahl für Anwendungsentwickler.

Qt ist einplattformübergreifendAnwendungsframework mit offiziellen Ports für Windows, MacOS und mehr sowie experimentellen Community-Ports für Android, iPhone und WebOS. Eine starke plattformübergreifende Unterstützung war eines der ursprünglichen Prinzipien von Qt und zeigt sich in der Reife der offiziellen Ports. Da Ubuntu Light auf Computern mit Windows installiert wird und Ubuntu One auf Android und dem iPhone landet, benötigen wir Interoperabilität mit anderen Plattformen. Es gibt auch eine große Anzahl von Entwicklern, die bereits wissen, wie man Windows anspricht, und die mit Qt auch Ubuntu-Benutzer erreichen können.

Qt hat eine ziemlich ausgereifteTouch-EingabeSystem, das jetzt Multi-Touch und Gesten (einschließlich QML) unterstützt, obwohl es nur unter Windows 7 und Mac OS X 10.6 vollständig ist. In der Zwischenzeit hat Canonical mit der Community zusammengearbeitet, um ein Low-Level-Multi-Touch-Framework für Linux und X11 zu entwickeln, das Qt und anderen Toolkits zugutekommt. Diese Bemühungen werden sich irgendwann in der Mitte treffen.

Insgesamt denke ich, dass Qt Leuten, die Anwendungen für (und auf) Ubuntu entwickeln möchten, viel zu bieten hat, insbesondere jetzt. Es unterstützt bereits beliebte plattformübergreifende Anwendungen wie VLC, ganz zu schweigen von der gesamten Kubuntu-Distribution. Ich habe es verpasst, als dies letztes Jahr geschah, aber Qt ist jetzt entweder unter LGPL 2.1 oder GPL 3.0 verfügbar, was es für praktisch jede Ubuntu-Anwendung geeignet machen sollte. Es hat eine starke kommerzielle Unterstützung sowie eine große Entwickler-Community. Natürlich wird keine einzelne Lösung alle Anforderungen der Entwickler erfüllen, und Ubuntu unterstützt aus diesem Grund mehrere Toolkits und Frameworks, aber Qt scheint ein großartiges Werkzeug in unserem Werkzeugkasten für die Zukunft zu sein.

EinArs Technica-ArtikelDie Diskussion dieses Blogbeitrags bietet einige Erkenntnisse:

Qt kann Drittanbieter-Entwickler zu Linux bringen

Obwohl Gtk+ immer noch wertvoll ist und es eine Reihe von Gründen gibt, es weiterhin zum Erstellen nativer Linux-Software zu verwenden, ist Qt jetzt die offensichtliche Wahl für ISVs, die mehrere Plattformen ansprechen. Qt macht es außerordentlich einfach, sich an das native Erscheinungsbild der zugrunde liegenden Plattform anzupassen oder eine vollständig benutzerdefinierte Benutzeroberfläche zu erstellen, die optimal auf ein Zielgerät oder einen Formfaktor abgestimmt ist.

Da Nokia und Intel MeeGo auf einer breiten Palette von Geräten anbieten, wird dies einige große kommerzielle Softwareanbieter anziehen. Für diese Softwareunternehmen wäre es relativ einfach, ihre mobilen Qt-Anwendungen mit demselben Code, den sie für MeeGo verwenden, auf den Linux-Desktop zu bringen. Qt ist speziell darauf ausgelegt, dies zu vereinfachen. Dies wäre ein großer Gewinn für Desktop-Linux, da es Anwendungen von Drittanbietern bringen würde, die sonst nicht verfügbar wären.

Es ist erwähnenswert, dass einige namhafte Anbieter mobiler Software aufgrund der Unterstützung des Toolkits durch Nokia bereits eifrig auf Qt umsteigen. Das Unternehmen für mobiles Videostreaming Qik arbeitet beispielsweise an einem experimentellen Qt-basierten Port seiner beliebten Anwendung mit dem Ziel, diese auf MeeGo zu bringen.

Der Autor des Artikels ist der Entwickler der Gwibber IM-App und verfügt daher über einige Erfahrung in der Entwicklung von GUIs für Linux.

Answer

Technischer Leiter von UbuntuMatt Zimmermans Blogist auch informativ:

In diesem Sinne habe ich in letzter Zeit über Qt nachgedacht. Wir möchten die Entwicklung von Anwendungen für Ubuntu schnell, einfach und unkompliziert machen, und Qt ist für Anwendungsentwickler eine Option, die es wert ist, in Erwägung gezogen zu werden. Als ich darüber nachdachte, wurde mir klar, dass es viele Gemeinsamkeiten zwischen den Stärken von Qt und einigen der neuen Richtungen in Ubuntu gibt:

Qt hat eine lange Geschichte der Nutzung aufARM sowie x86, aufgrund der Beliebtheit auf eingebetteten Geräten. Verbraucherprodukte werden seit über 10 Jahren mit Qt auf ARM entwickelt. Wir stellen Ubuntu-Produkte seit fast zwei Jahren für ARM zur Verfügung und 10.10 unterstützt mehr ARM-Boards als je zuvor, darunter Referenzboards von Freescale, Marvell und TI. Qt fügt ARMv7-Optimierungen hinzu, um die neuesten ARM-Chips zu nutzen. Wir tun dies, um OEMs eine Auswahl an Hardware zu bieten, ohne die Auswahl an Software zu beeinträchtigen. Qt bewahrt diese Auswahl für Anwendungsentwickler.

Qt ist einplattformübergreifendAnwendungsframework mit offiziellen Ports für Windows, MacOS und mehr sowie experimentellen Community-Ports für Android, iPhone und WebOS. Eine starke plattformübergreifende Unterstützung war eines der ursprünglichen Prinzipien von Qt und zeigt sich in der Reife der offiziellen Ports. Da Ubuntu Light auf Computern mit Windows installiert wird und Ubuntu One auf Android und dem iPhone landet, benötigen wir Interoperabilität mit anderen Plattformen. Es gibt auch eine große Anzahl von Entwicklern, die bereits wissen, wie man Windows anspricht, und die mit Qt auch Ubuntu-Benutzer erreichen können.

Qt hat eine ziemlich ausgereifteTouch-EingabeSystem, das jetzt Multi-Touch und Gesten (einschließlich QML) unterstützt, obwohl es nur unter Windows 7 und Mac OS X 10.6 vollständig ist. In der Zwischenzeit hat Canonical mit der Community zusammengearbeitet, um ein Low-Level-Multi-Touch-Framework für Linux und X11 zu entwickeln, das Qt und anderen Toolkits zugutekommt. Diese Bemühungen werden sich irgendwann in der Mitte treffen.

Insgesamt denke ich, dass Qt Leuten, die Anwendungen für (und auf) Ubuntu entwickeln möchten, viel zu bieten hat, insbesondere jetzt. Es unterstützt bereits beliebte plattformübergreifende Anwendungen wie VLC, ganz zu schweigen von der gesamten Kubuntu-Distribution. Ich habe es verpasst, als dies letztes Jahr geschah, aber Qt ist jetzt entweder unter LGPL 2.1 oder GPL 3.0 verfügbar, was es für praktisch jede Ubuntu-Anwendung geeignet machen sollte. Es hat eine starke kommerzielle Unterstützung sowie eine große Entwickler-Community. Natürlich wird keine einzelne Lösung alle Anforderungen der Entwickler erfüllen, und Ubuntu unterstützt aus diesem Grund mehrere Toolkits und Frameworks, aber Qt scheint ein großartiges Werkzeug in unserem Werkzeugkasten für die Zukunft zu sein.

EinArs Technica-ArtikelDie Diskussion dieses Blogbeitrags bietet einige Erkenntnisse:

Qt kann Drittanbieter-Entwickler zu Linux bringen

Obwohl Gtk+ immer noch wertvoll ist und es eine Reihe von Gründen gibt, es weiterhin zum Erstellen nativer Linux-Software zu verwenden, ist Qt jetzt die offensichtliche Wahl für ISVs, die mehrere Plattformen ansprechen. Qt macht es außerordentlich einfach, sich an das native Erscheinungsbild der zugrunde liegenden Plattform anzupassen oder eine vollständig benutzerdefinierte Benutzeroberfläche zu erstellen, die optimal auf ein Zielgerät oder einen Formfaktor abgestimmt ist.

Da Nokia und Intel MeeGo auf einer breiten Palette von Geräten anbieten, wird dies einige große kommerzielle Softwareanbieter anziehen. Für diese Softwareunternehmen wäre es relativ einfach, ihre mobilen Qt-Anwendungen mit demselben Code, den sie für MeeGo verwenden, auf den Linux-Desktop zu bringen. Qt ist speziell darauf ausgelegt, dies zu vereinfachen. Dies wäre ein großer Gewinn für Desktop-Linux, da es Anwendungen von Drittanbietern bringen würde, die sonst nicht verfügbar wären.

Es ist erwähnenswert, dass einige namhafte Anbieter mobiler Software aufgrund der Unterstützung des Toolkits durch Nokia bereits eifrig auf Qt umsteigen. Das Unternehmen für mobiles Videostreaming Qik arbeitet beispielsweise an einem experimentellen Qt-basierten Port seiner beliebten Anwendung mit dem Ziel, diese auf MeeGo zu bringen.

Der Autor des Artikels ist der Entwickler der Gwibber IM-App und verfügt daher über einige Erfahrung in der Entwicklung von GUIs für Linux.

Question 4

Meine Meinung zu den technischen/pragmatischen Gründen: Nokia hat Trolltech gekauft und viel in QT investiert. Es ist leicht und wurde über Jahre für die mobile Plattform optimiert. Unabhängig von Ihrer aktuellen Meinung zu Nokia war das N900 seiner Zeit um Jahre voraus ... und es basierte auf Debian/QT ... aber teuer. Ich habe jedoch keine wirklichen Kenntnisse über die Entscheidungen.

Answer

Meine Meinung zu den technischen/pragmatischen Gründen: Nokia hat Trolltech gekauft und viel in QT investiert. Es ist leicht und wurde über Jahre für die mobile Plattform optimiert. Unabhängig von Ihrer aktuellen Meinung zu Nokia war das N900 seiner Zeit um Jahre voraus ... und es basierte auf Debian/QT ... aber teuer. Ich habe jedoch keine wirklichen Kenntnisse über die Entscheidungen.

Warum wählt Canonical für die nächste Generation von Unity QT statt GTK?

Antwort1

Antwort2

Antwort3

Qt kann Drittanbieter-Entwickler zu Linux bringen

Antwort4

verwandte Informationen