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

Es wurde so viel geschrieben, dass ich etwas verwirrt bin, aber wenn ich mich nicht irre, baut Canonical die nächste Generation von Unity für mobile Geräte mit Qt und in naher Zukunft wird auch der Desktop auf qt migriert.

Ich wollte nur wissen, aus welchen technischen und / oder politischen Gründen diese Entscheidung getroffen wurde und welche Konsequenzen dies für die derzeit vorhandenen Ubuntu-Desktop-Anwendungen haben könnte.

Die Antwort finden Sie auf der Mailingliste und im Blog von Mark Shuttleworth . Dieser Blog-Beitrag beantwortet es wahrscheinlich am besten:

Im Rahmen unserer Planung für Natty + 1 müssen wir auf der CD Speicherplatz für Qt-Bibliotheken finden und mit Qt entwickelte Anwendungen für die Aufnahme auf die CD und die Standardinstallation von Ubuntu auswerten.

Benutzerfreundlichkeit und effektive Integration sind wichtige Werte in unserer Benutzererfahrung. Es ist uns wichtig, dass die von uns ausgewählten Anwendungen miteinander und mit dem gesamten System harmonieren. In der Vergangenheit bedeutete dies, dass wir Anwendungen, die mit Gtk geschrieben wurden, sehr viel Vorrang einräumen, da ein gewisses Maß an Harmonie standardmäßig durch die Verwendung desselben Entwickler-Toolkits erzielt wird. Da OpenOffice und Firefox von Anfang an dabei waren, ist Gtk natürlich keine absolute Voraussetzung. Was ich jetzt argumentiere, ist, dass es die Werte sind, die wichtig sind, und das Toolkit ist nur ein Mittel zu diesem Zweck. Wir sollten Apps dahingehend bewerten, wie gut sie die Anforderungen erfüllen, und sie nicht auf der Grundlage technischer Entscheidungen des Entwicklers beeinträchtigen.

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

• ist es freie Software?
• ist es klassenbester?
• Kann es in die Systemeinstellungen und -einstellungen integriert werden?
• lässt es sich in andere Anwendungen integrieren?
• ist es für menschen zugänglich, die keine maus oder tastatur benutzen können?
• Entspricht es dem Rest des Systems?

Natürlich hat die Wahl des Entwicklers von Qt keinen Einfluss auf die ersten beiden. Qt selbst ist seit langer Zeit unter der GPL verfügbar und wurde in jüngerer Zeit unter der LGPL verfügbar. Und es gibt eine Menge erstklassiger Software, die mit Qt geschrieben wurde. Es ist ein sehr leistungsfähiges Toolkit.

Systemeinstellungen und Vorlieben sind jedoch seit langem ein Grund für die Reibung zwischen Qt und Gtk. Die Integration mit Systemeinstellungen und -präferenzen ist entscheidend für die Zugehörigkeit einer Anwendung zum System. Dies wirkt sich auf die Fähigkeit aus, diese Anwendung mit denselben Tools zu verwalten, die auch für die Verwaltung aller anderen Anwendungen verwendet werden, sowie auf die Art der Einstellungen und Vorlieben, die Benutzer mit der App erzielen können. Dies war traditionell ein Problem bei Qt / KDE-Anwendungen unter Ubuntu, da Gtk-Apps alle einen zentral verwaltbaren Einstellungsspeicher verwenden und KDE-Apps die Dinge anders ausführen.

Um dies zu beheben, treibt Canonical die Entwicklung von dconf-Bindungen für Qt voran, sodass 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 dconf offensichtlich sehr gut kennt, 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 selbstverständlich ist und die Semantik und den Stil von dconf vollständig zum Ausdruck bringt.

Das Qt-Team hat lange Zeit gut in der breiteren Ubuntu-Community gearbeitet - wir haben alle sechs Monate eine großartige Qt-Vertretung bei UDS, das Kubuntu-Team verfügt über umfassende Erfahrung und Interesse an Qt-Verpackung und -Wartung, es gibt viel guten technischen Austausch zwischen Qt Upstream und verschiedenen Teile der Ubuntu-Community, einschließlich Canonical. Zum Beispiel arbeiten Qt-Leute daran, uTouch zu integrieren.

Ich würde an den offensichtlichen Stellen zwischen „Qt“ und „KDE“ unterscheiden. Eine KDE-App weiß nichts über die Konfiguration des dconf-Systems und kann daher nicht einfach in den Ubuntu-Desktop integriert werden. Also werden wir Amarok nicht vorschlagen, Banshee bald zu ersetzen! Aber ich halte es für absolut plausibel, dass dconf, wenn es einmal gute Qt-Bindungen hat, von der KDE-Community berücksichtigt wird. Es gibt bessere Leute, die das Gespräch leiten können, wenn sie wollen, deshalb werde ich die Idee hier nicht weiter verfolgen. Sollte eine KDE-App zusätzlich zu den KDE-Standardmechanismen das Sprechen von dconf erlernen, was unkompliziert sein sollte, wäre dies ein Kandidat für die Ubuntu-Standardinstallation.

Die Entscheidung, Qt gegenüber offen zu sein, ist in keiner Weise eine Kritik an GNOME. Es ist ein Fest der Vielfalt und Komplexität freier Software. Diese Werte der Benutzerfreundlichkeit und Integration bleiben gemeinsame Werte von 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 dies der Fall ist, wäre unsere Bereitschaft, diesen Pfad zu beschreiten, ein Beitrag zur Führung. Es ist viel einfacher, ein lebendiges Ökosystem zu schaffen, wenn Sie sozusagen eine gewisse Abweichung von der kanonischen Methode akzeptieren. Unsere Arbeit am Design konzentriert sich auf GNOME, wobei Einstellungen und Präferenzen den aktuellen Schwerpunkt bilden, wenn wir zu GNOME 3.0 und gtk3 übergehen.

Natürlich ist dies eine perfekte Gelegenheit für diejenigen, die sich über diese Beziehung lustig machen würden, aber meiner Meinung nach ist es am wichtigsten, dass wir eine solide Beziehung zu Menschen haben, die tatsächlich Anwendungen unter dem GNOME-Banner schreiben. Wir wollen der beste Weg sein, um die harte Arbeit dieser Entwickler freier Software von Bedeutung zu machen , und damit die beste Möglichkeit, um sicherzustellen, dass sie jeden Tag einen echten Unterschied in Millionen von Leben bewirkt, und die beste Möglichkeit, um sie zu verbinden ihre Benutzer.

An die guten Leute bei Trolltech, jetzt Nokia, die Qt zu einem großartigen Toolkit gemacht haben - danke. An Entwickler, die es nutzen und Teil der Ubuntu-Erfahrung sein möchten - willkommen.

GTK + unterstützt keine Auflösungsunabhängigkeit. Moderne Mobilgeräte haben eine extrem hohe Pixeldichte. Wenn Sie eine GTK + -Anwendung auf einem mobilen Bildschirm ausführen, sind alle Elemente der Benutzeroberfläche so klein, dass sie nicht mehr verwendet werden können.

Dies ist ein offener Bug in GTK + seit 2008, bis er 2014 geschlossen wurde. "Wir haben jetzt Unterstützung für Hi-DPI-Skalen - es ist nicht ganz dasselbe, aber nah genug, um diesen Bug überflüssig zu machen."

Als GTK + 3 veröffentlicht wurde, bot sich für das Projekt die perfekte Gelegenheit, die Unabhängigkeit von der Auflösung zu erhöhen, da sie ohnehin die Kompatibilität beeinträchtigten. Sie entschieden sich dagegen, und jetzt ist es für sie wirklich zu spät.

Auf der GTK + Roadmap ist für die Veröffentlichung nach 4.0 eine Unabhängigkeit von der Auflösung geplant. Sie werden also 4.0 veröffentlichen und danach die Hauptveröffentlichung. Wenn sie sich an diesen Plan halten, muss sogar Desktop-GNU / Linux auf GTK + verzichten, da hochauflösende Desktop-Monitore und Laptop-Monitore bereits verfügbar sind und bald zur neuen Normalität werden.

Meine Meinung zu den technischen / pragmatischen Gründen: Nokia hat Trolltech gekauft und viel in QT investiert. Es ist leichtgewichtig und hat jahrelange Optimierungen für die mobile Plattform. Unabhängig von Ihrer aktuellen Meinung über Nokia war das N900 seiner Zeit um Jahre voraus ... und es war debian- / QT-basiert ... aber teuer. Ich habe jedoch keine wirkliche Kenntnis von den Entscheidungen.

Der Blog von Matt Zimmerman, CTO von Ubuntu, ist auch informativ:

In diesem Sinne habe ich in letzter Zeit über Qt nachgedacht. Wir möchten, dass die Entwicklung von Anwendungen für Ubuntu schnell, einfach und problemlos vonstatten geht, und Qt ist für Anwendungsentwickler eine Option, die es sich zu erkunden lohnt. Als ich darüber nachdachte, wurde mir klar, dass die Stärken von Qt und einige der neuen Richtungen in Ubuntu einiges gemeinsam haben:

• Qt hat eine lange Tradition in der Verwendung von ARM und x86 , da es auf Embedded-Geräten sehr beliebt ist. Konsumgüter werden seit über 10 Jahren mit Qt on ARM hergestellt. Wir stellen seit fast zwei Jahren Ubuntu-Produkte für ARM zur Verfügung und 10.10 unterstützt mehr ARM-Boards als je zuvor, einschließlich Referenzboards von Freescale, Marvell und TI. Qt fügt ARMv7-Optimierungen hinzu, um die neuesten ARM-Chips zu unterstützen. Wir tun dies, um OEMs eine Auswahl an Hardware zu bieten, ohne die Auswahl an Software zu beeinträchtigen. Qt behält diese Auswahl für Anwendungsentwickler bei.
• Qt ist ein plattformübergreifendes Anwendungsframework 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 Häfen. Da Ubuntu Light auf Computern mit Windows installiert ist 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 auf Windows abzielt, und die Ubuntu-Benutzer auch durch Auswahl von Qt erreichen können.
• Qt verfügt über ein ausgereiftes Touch-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 einfaches Multi-Touch-Framework für Linux und X11 zu entwickeln, das Qt und anderen Toolkits zugute kommt. Diese Bemühungen werden sich irgendwann in der Mitte treffen.

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

Ein Artikel von Ars Technica , der diesen Blogeintrag behandelt, bietet einige Einblicke:

Qt kann Entwickler von Drittanbietern zu Linux bringen

Obwohl Gtk + immer noch von Nutzen 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 auf mehrere Plattformen abzielen. Mit Qt ist es außerordentlich einfach, sich an das native Erscheinungsbild der zugrunde liegenden Plattform anzupassen oder eine vollständig benutzerdefinierte Benutzeroberfläche zu erstellen, die sich optimal für ein Zielgerät oder einen Formfaktor eignet.

Da Nokia und Intel MeeGo auf eine breite Palette von Geräten bringen, wird es einige große kommerzielle Softwareanbieter anziehen. Für diese Softwarefirmen wäre es relativ einfach, ihre mobilen Qt-Anwendungen mit demselben Code, den sie auf MeeGo verwenden, auf den Linux-Desktop zu bringen. Qt wurde speziell entwickelt, um 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 prominente Anbieter von mobiler Software Qt aufgrund der Unterstützung von Nokia für das Toolkit bereits sehr begrüßen. Das mobile Video-Streaming-Unternehmen Qik arbeitet beispielsweise an einem experimentellen Qt-basierten Port seiner beliebten Anwendung, um ihn für MeeGo bereitzustellen.

Der Autor des Artikels ist der Schöpfer der Gwibber IM-App, daher hat er einige Erfahrung in der Entwicklung von GUIs für Linux.