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.