Mengapa Canonical memilih QT daripada GTK untuk generasi Unity selanjutnya?

Sudah banyak yang ditulis sehingga saya agak bingung, tetapi jika saya tidak salah, Canonical sedang membangun generasi Unity berikutnya untuk perangkat seluler dengan Qt, dan dalam waktu dekat desktop juga akan dimigrasikan ke qt.

Saya hanya ingin mengetahui alasan teknis dan / atau politis yang mendorong keputusan ini, dan apa akibatnya bagi aplikasi desktop Ubuntu yang ada saat ini.

Anda dapat menemukan jawabannya di milis dan di blog Mark Shuttleworth . Posting blog ini mungkin menjawab yang terbaik:

Sebagai bagian dari perencanaan kami untuk Natty +1, kami perlu menemukan beberapa ruang pada CD untuk pustaka Qt, dan kami akan mengevaluasi aplikasi yang dikembangkan dengan Qt untuk dimasukkan pada CD dan pemasangan default Ubuntu.

Kemudahan penggunaan, dan integrasi yang efektif, adalah nilai-nilai kunci dalam pengalaman pengguna kami. Kami peduli bahwa aplikasi yang kami pilih selaras satu sama lain dan sistem secara keseluruhan. Secara historis, itu berarti bahwa kami telah memberikan preferensi yang sangat kuat untuk aplikasi yang ditulis menggunakan Gtk, karena sejumlah harmoni datang secara default dari penggunaan toolkit pengembang yang sama. Yang mengatakan, dengan OpenOffice dan Firefox telah ada sejak awal, Gtk jelas bukan persyaratan mutlak. Yang saya perdebatkan sekarang adalah bahwa nilai-nilai itulah yang penting, dan toolkit hanya sarana untuk mencapai tujuan itu. Kita harus mengevaluasi aplikasi berdasarkan seberapa baik mereka memenuhi persyaratan, bukan mengurangi mereka berdasarkan pilihan teknis yang dibuat oleh pengembang.

Dalam mengevaluasi aplikasi untuk pemasangan default Ubuntu, kita harus bertanya:

• apakah ini perangkat lunak bebas?
• apakah ini yang terbaik di kelasnya?
• apakah itu terintegrasi dengan pengaturan dan preferensi sistem?
• apakah itu terintegrasi dengan aplikasi lain?
• apakah ini dapat diakses oleh orang yang tidak dapat menggunakan mouse, atau keyboard?
• apakah ini terlihat dan terasa konsisten dengan sistem lainnya?

Tentu saja, pilihan pengembang Qt tidak memiliki pengaruh pada dua yang pertama. Qt sendiri telah tersedia di bawah GPL sejak lama, dan baru-baru ini menjadi tersedia di bawah LGPL. Dan ada banyak perangkat lunak terbaik di kelasnya yang ditulis dengan Qt, ini adalah toolkit yang sangat cakap.

Pengaturan sistem dan prefs, bagaimanapun, telah lama menjadi penyebab gesekan antara Qt dan Gtk. Integrasi dengan pengaturan dan preferensi sistem sangat penting untuk rasa aplikasi "milik" pada sistem. Ini memengaruhi kemampuan untuk mengelola aplikasi tersebut menggunakan alat yang sama yang digunakan untuk mengelola semua aplikasi lain, dan jenis pengalaman pengaturan dan preferensi yang dapat dimiliki pengguna dengan aplikasi tersebut. Ini secara tradisional menjadi masalah dengan aplikasi Qt / KDE di Ubuntu, karena aplikasi Gtk semuanya menggunakan toko preferensi yang dikelola secara terpusat, dan aplikasi KDE melakukan hal-hal secara berbeda.

Untuk mengatasinya, Canonical mendorong pengembangan binding dconf untuk Qt, sehingga memungkinkan untuk menulis aplikasi Qt yang menggunakan kerangka pengaturan yang sama dengan yang lainnya di Ubuntu. Kami telah membuat kontrak dengan Ryan Lortie, yang jelas mengenal dconf dengan sangat baik, dan dia akan bekerja dengan beberapa orang di Canonical yang telah menggunakan Qt untuk pekerjaan pengembangan kustom untuk pelanggan. Kami yakin hasilnya akan alami untuk pengembang Qt, dan ekspresi lengkap dari semantik dan gaya dconf.

Tim Qt telah lama bekerja dengan baik di komunitas Ubuntu yang lebih luas - kami memiliki perwakilan Qt yang hebat di UDS setiap enam bulan, tim Kubuntu memiliki pengalaman dan minat yang mendalam pada pengemasan dan pemeliharaan Qt, ada banyak pertukaran teknis yang baik antara Qt hulu dan berbagai bagian dari komunitas Ubuntu, termasuk Canonical. Sebagai contoh, orang-orang Qt sedang bekerja untuk mengintegrasikan uTouch.

Saya akan menggambar perbedaan antara "Qt" dan "KDE" di tempat yang jelas. Aplikasi KDE tidak tahu apa-apa tentang konfigurasi sistem dconf, dan sebagai hasilnya tidak dapat dengan mudah diintegrasikan dengan desktop Ubuntu. Jadi kita tidak akan mengusulkan Amarok untuk menggantikan Banshee dalam waktu dekat! Tapi saya pikir itu sepenuhnya masuk akal bahwa dconf, setelah memiliki ikatan Qt yang bagus, dipertimbangkan oleh komunitas KDE. Ada orang yang lebih baik untuk memimpin percakapan itu jika mereka mau, jadi saya tidak akan mendorong ide lebih jauh di sini. Namun demikian, seandainya aplikasi KDE belajar berbicara dconf di samping mekanisme KDE standar, yang harus langsung, itu akan menjadi kandidat untuk instalasi default Ubuntu.

Keputusan untuk terbuka pada Qt sama sekali bukan kritik terhadap GNOME. Ini adalah perayaan keragaman dan kompleksitas perangkat lunak bebas. Nilai-nilai kemudahan penggunaan dan integrasi tetap nilai bersama dengan GNOME, dan dasar yang bagus untuk kolaborasi dengan pengembang dan anggota proyek GNOME. Mungkin GNOME sendiri akan merangkul Qt, mungkin tidak, tetapi jika ya, kesediaan kita untuk merintis jalan ini akan menjadi kontribusi dalam kepemimpinan. Jauh lebih mudah untuk membuat ekosistem yang hidup jika Anda menerima sejumlah divergensi dari cara kanonik, sehingga untuk berbicara Pekerjaan kami pada desain berpusat di sekitar GNOME, dengan pengaturan dan preferensi fokus saat ini saat kami pindah ke GNOME 3.0 dan gtk3.

Tentu saja, ini adalah kesempatan sempurna bagi mereka yang akan mengolok-olok hubungan itu untuk melakukannya, tetapi menurut saya yang paling penting adalah hubungan yang solid yang kita miliki dengan orang-orang yang benar-benar menulis aplikasi di bawah bendera GNOME. Kami ingin menjadi cara terbaik untuk menjadikan kerja keras para pengembang perangkat lunak gratis itu penting , yang kami maksudkan, cara terbaik untuk memastikan itu membuat perbedaan nyata dalam jutaan kehidupan setiap hari, dan cara terbaik untuk menghubungkan mereka dengan pengguna mereka.

Kepada orang-orang baik di Trolltech, sekarang Nokia, yang telah menjadikan Qt alat yang hebat - terima kasih. Untuk para pengembang yang ingin menggunakannya dan menjadi bagian dari pengalaman Ubuntu - selamat datang.

GTK + tidak mendukung independensi resolusi, Perangkat seluler modern memiliki kerapatan piksel sangat tinggi. Jika Anda menjalankan aplikasi GTK + di layar seluler, semua elemen antarmuka pengguna akan menjadi sangat kecil sehingga tidak dapat digunakan.

Ini telah menjadi bug terbuka pada GTK + sejak 2008 hingga ditutup pada tahun 2014 dengan "kami memiliki dukungan skala hi-dpi sekarang - itu bukan hal yang sama, tetapi cukup dekat untuk membuat bug ini usang" komentar.

Ketika GTK + 3 dirilis, proyek ini memiliki peluang sempurna untuk menambah independensi resolusi, karena mereka tetap melanggar kompatibilitas. Mereka memilih untuk tidak, dan sekarang sudah sangat terlambat bagi mereka.

Pada GTK + Roadmap , resolusi independensi direncanakan untuk rilis setelah 4.0, sehingga mereka akan merilis 4.0 kemudian rilis utama setelah itu akan memilikinya. Jika mereka tetap pada rencana itu maka bahkan desktop GNU / Linux harus meninggalkan GTK + karena monitor desktop DPI tinggi dan monitor laptop sudah tersedia dan akan menjadi normal baru.

Saya mengambil alasan Teknis / pragmatis: Nokia membeli Trolltech dan menginvestasikan banyak ke QT. Ringan dan memiliki optimasi bertahun-tahun menuju platform seluler. Terlepas dari pendapat Anda tentang Nokia saat ini, N900 adalah tahun-tahun sebelumnya ... dan berbasis debian / QT ... tapi mahal. Namun, saya tidak memiliki pengetahuan nyata tentang keputusan tersebut.

Blog Ubuntu CTO Matt Zimmerman juga informatif:

Dalam semangat inilah saya memikirkan Qt baru-baru ini. Kami ingin membuatnya cepat, mudah dan tidak menyakitkan untuk mengembangkan aplikasi untuk Ubuntu, dan Qt adalah pilihan yang layak untuk dijelajahi oleh pengembang aplikasi. Dalam memikirkan hal ini, saya menyadari bahwa ada sedikit kesamaan antara kekuatan Qt dan beberapa arah baru di Ubuntu:

• Qt memiliki sejarah panjang penggunaan pada ARM dan juga x86 , karena menjadi populer di perangkat embedded. Produk konsumen telah dibangun menggunakan Qt pada ARM selama lebih dari 10 tahun. Kami telah membuat produk Ubuntu tersedia untuk ARM selama hampir dua tahun sekarang, dan 10.10 mendukung lebih banyak papan ARM dari sebelumnya, termasuk papan referensi dari Freescale, Marvell dan TI. Qt menambahkan optimisasi ARMv7 untuk memberi manfaat pada chip ARM terbaru. Kami melakukan ini untuk menawarkan OEM pilihan perangkat keras, tanpa mengorbankan pilihan perangkat lunak. Qt mempertahankan pilihan yang sama ini untuk pengembang aplikasi.
• Qt adalah kerangka kerja aplikasi lintas platform , dengan port resmi untuk Windows, MacOS, dan lainnya, dan port komunitas eksperimental ke Android, iPhone, dan WebOS. Dukungan lintas platform yang kuat adalah salah satu prinsip asli Qt, dan itu menunjukkan kematangan port resmi. Dengan Ubuntu Light yang diinstal pada komputer dengan Windows, dan Ubuntu One mendarat di Android dan iPhone, kita membutuhkan interoperabilitas dengan platform lain. Ada juga sejumlah besar pengembang yang sudah tahu bagaimana menargetkan Windows, yang dapat menjangkau pengguna Ubuntu juga dengan memilih Qt.
• Qt memiliki sistem input sentuh yang cukup matang , yang sekarang memiliki dukungan untuk multi-touch dan gerakan (termasuk QML), meskipun hanya lengkap pada Windows 7 dan Mac OS X 10.6. Sementara itu, Canonical telah bekerja dengan komunitas untuk mengembangkan kerangka kerja multi-touch tingkat rendah untuk Linux dan X11, untuk kepentingan Qt dan toolkit lainnya. Upaya ini pada akhirnya akan bertemu di tengah.

Secara keseluruhan, saya pikir Qt memiliki banyak hal untuk ditawarkan kepada orang-orang yang ingin mengembangkan aplikasi untuk (dan pada) Ubuntu, khususnya sekarang. Ini sudah mendukung aplikasi lintas platform populer seperti VLC, belum lagi seluruh distribusi Kubuntu. Saya melewatkannya ketika ini terjadi tahun lalu, tetapi Qt sekarang tersedia di bawah LGPL 2.1 atau GPL 3.0, yang seharusnya membuatnya cocok untuk hampir semua aplikasi Ubuntu. Ini memiliki dukungan komersial yang kuat serta komunitas pengembang besar. Tentu saja, tidak ada solusi tunggal yang memenuhi semua kebutuhan pengembang, dan Ubuntu mendukung beberapa toolkit dan kerangka kerja untuk alasan ini, tetapi Qt sepertinya merupakan alat yang hebat untuk ada di kotak alat kami untuk jalan di depan.

Sebuah artikel Ars Technica membahas posting blog ini menyediakan beberapa wawasan:

Qt dapat membawa pengembang pihak ketiga ke Linux

Meskipun Gtk + masih memiliki nilai dan ada sejumlah alasan untuk terus menggunakannya untuk membangun perangkat lunak Linux asli, Qt sekarang merupakan pilihan yang jelas untuk ISV yang menargetkan berbagai platform. Qt membuatnya sangat mudah untuk menyesuaikan dengan tampilan dan nuansa asli platform yang mendasarinya atau membangun antarmuka pengguna yang benar-benar khusus yang secara optimal cocok untuk perangkat target atau faktor bentuk.

Ketika Nokia dan Intel membawa MeeGo ke berbagai perangkat, itu akan menarik beberapa vendor perangkat lunak komersial utama. Akan relatif mudah bagi perusahaan-perusahaan perangkat lunak untuk membawa aplikasi Qt mobile mereka ke desktop Linux menggunakan kode yang sama yang mereka gunakan pada MeeGo. Qt dirancang khusus untuk membuatnya mudah. Ini akan menjadi kemenangan besar untuk desktop Linux karena akan membawa aplikasi pihak ketiga yang tidak akan tersedia.

Perlu dicatat bahwa beberapa vendor perangkat lunak seluler terkemuka sudah bersemangat merangkul Qt karena dukungan Nokia untuk toolkit ini. Perusahaan streaming video seluler Qik, misalnya, sedang mengerjakan port eksperimental berbasis Qt dari aplikasi populernya dengan tujuan membawanya ke MeeGo.

Penulis artikel ini adalah pencipta aplikasi IM Gwibber, jadi ia memiliki pengalaman mengembangkan GUI untuk Linux.