Canonical, neden Unity'nin yeni nesli için GTK yerine QT'yi seçiyor?


33

Kafam karıştı, ama yanılmıyorsam Canonical Qt'li mobil cihazlar için yeni nesil Unity'yi kuruyor ve yakın gelecekte masaüstü de qt'ye taşınacak.

Sadece bu kararı veren teknik ve / veya politik nedenleri ve şu anda mevcut Ubuntu masaüstü uygulamaları için ne gibi sonuçlar doğurabileceğini bilmek istedim.


3
GTK’da programlama çok büyük bir acıdır, çünkü OO kavramlarını C’ye atmak için yapılan sefil bir girişim olan GObject’in ürünü değildir. C ++ mükemmel olmayabilir, ancak GObject bar soooo'yu çok düşük ayarlıyor.
weberc2

Yanıtlar:


23

Cevapları posta listesinde ve Mark Shuttleworth'un blogunda bulabilirsiniz . Bu blog yazısı muhtemelen en iyi yanıtı veriyor:

Natty + 1 için yaptığımız planlamanın bir parçası olarak, Qt kütüphaneleri için CD'de biraz yer bulmamız gerekecek ve CD'ye dahil olmak için Qt ile geliştirilen uygulamaları ve Ubuntu'nun varsayılan kurulumunu değerlendireceğiz.

Kullanım kolaylığı ve etkili entegrasyon, kullanıcı deneyimimizdeki kilit değerlerdir. Seçtiğimiz uygulamaların birbiriyle ve bir bütün olarak sistemle uyumlu olmasını önemsiyoruz. Tarihsel olarak, bu, Gtk kullanılarak yazılmış uygulamaları tercih etmemiz gerektiği anlamına geliyordu, çünkü varsayılan olarak aynı geliştirici araç setinin kullanımından belirli bir miktarda uyum geliyor. Bu, OpenOffice ve Firefox'un en başından beri orada olmasıyla Gtk kesinlikle mutlak bir gereklilik değildir. Şimdi tartıştığım şey, bunun önemli olan değerler olduğunu ve araç setinin sadece bunun için bir araç olduğudur. Uygulamaları, gereklilikleri ne kadar iyi karşıladıklarına göre değerlendirmeliyiz, geliştiricinin yaptığı teknik seçimler temelinde önyargıları değil.

Ubuntu varsayılan kurulumu için bir uygulamayı değerlendirirken, şunu sormalıyız:

  • özgür yazılım mı?
  • Sınıfının en iyisi mi?
  • sistem ayarları ve tercihleri ​​ile bütünleşir mi?
  • diğer uygulamalarla bütünleşir mi?
  • Fareyi veya klavyeyi kullanamayan insanlar için erişilebilir mi?
  • sistemin geri kalanıyla tutarlı görünüyor ve hissediyor mu?

Tabii ki, geliştiricinin Qt seçiminin ilk ikisi üzerinde etkisi yoktur. Qt'nun kendisi GPL altında uzun süredir mevcuttu ve yakın zamanda LGPL'de mevcuttu. Ve Qt ile yazılmış çok sayıda sınıfının en iyisi yazılımı var, bu çok yetenekli bir araç seti.

Bununla birlikte, sistem ayarları ve tercihleri, Qt ve Gtk arasında sürtünme nedeni olmuştur. Sistem ayarları ve tercihleri ​​ile entegrasyon sisteme “ait” bir uygulama anlamında önemlidir. Bir uygulamayı diğer tüm uygulamaları yönetmek için kullandığı araçları kullanarak ve kullanıcıların uygulamada yaşayabileceği ayar ve tercih deneyimini kullanma becerisini etkiler. Bu geleneksel olarak Ubuntu'daki Qt / KDE uygulamalarında bir sorun olmuştur, çünkü Gtk uygulamalarının tümü merkezi olarak yönetilebilir bir tercihler deposunu kullanır ve KDE uygulamaları her şeyi farklı yapar.

Canonical, bunu ele almak için Qt için dconf ciltlemelerinin geliştirilmesine yön veriyor, böylece Ubuntu'daki her şeyle aynı ayar çerçevesini kullanan bir Qt uygulaması yazmak mümkün. Dconf'u çok iyi bilen Ryan Lortie ile sözleşme yaptık ve Canonical'da müşteriler için özel geliştirme çalışmaları için Qt kullanan bazı kişilerle birlikte çalışacağız. Sonuçların Qt geliştiricileri için doğal olacağından ve dconf'un anlambilim ve stilinin eksiksiz bir ifadesinden eminiz.

Qt ekibi, Ubuntu topluluğunda uzun süredir iyi çalıştı - her altı ayda bir UDS’de büyük Qt temsilimiz var, Kubuntu ekibi Qt paketleme ve bakım konusunda derin deneyime ve ilgiye sahip, Qt upstream ve çeşitli Canonical dahil olmak üzere Ubuntu topluluğunun bölümleri. Örneğin, Qt millet uTouch'ı entegre etmek için çalışıyor.

Belli yerlerde “Qt” ve “KDE” arasında bir ayrım çizerdim. Bir KDE uygulaması dconf sistemi yapılandırması hakkında hiçbir şey bilmez ve sonuç olarak Ubuntu masaüstüyle kolayca bütünleşemez. Öyleyse, kısa bir süre sonra Banshee'nin yerine Amarok'u teklif etmeyeceğiz! Ancak bence Dconf'un, büyük Qt bağlarına sahip olduktan sonra KDE topluluğu tarafından düşünülmesinin tamamen makul olduğunu düşünüyorum. İsterlerse bu sohbeti yönlendirecek daha iyi insanlar var, bu yüzden fikri burada daha fazla ilerletmeyeceğim. Bununla birlikte, bir KDE uygulaması, basit olması gereken standart KDE mekanizmalarına ek olarak dconf ile konuşmayı öğrenirse, Ubuntu varsayılan kurulumu için bir aday olacaktır.

Qt'ye açık olma kararı hiçbir şekilde GNOME eleştirisi değildir. Özgür yazılımın çeşitliliğinin ve karmaşıklığının bir kutlaması. Kullanım kolaylığı ve entegrasyon değerleri, GNOME ile paylaşılan değerler ve GNOME geliştiricileri ve proje üyeleri ile işbirliği için mükemmel bir temel olmaya devam ediyor. Muhtemelen GNOME'un kendisi Qt'yi kucaklayacaktır, belki de değil, ancak o zaman bu izi yakmaya istekliyiz, liderliğe katkısı olur. Kanonik yoldan belirli bir miktar sapmayı kabul ederseniz, canlı bir ekosistem yapmak çok daha kolaydır, tabiri caizse, tasarım çalışmalarımız GNOME 3.0 ve gtk3'e geçerken mevcut odağı ayarlayarak ve tercih ederek odaklanır.

Tabii ki, bu ilişkide eğlenmek isteyenler için mükemmel bir fırsat, ama benim görüşüme göre en önemlisi GNOME bayrağı altında uygulama yazan insanlarla olan sağlam ilişki. Biz bu ücretsiz yazılım geliştiricilerin zor işi yapmak için en iyi yolu olmak istiyorum olsun biz demek hangi, her gün Milyonlarca insanın hayatında gerçek bir fark yapar sağlamanın en iyi yolu, ve bunları bağlamak için en iyi yolu onların kullanıcıları.

QT'yi harika bir araç seti yapan Nokia, şimdi Trolltech'teki iyi insanlara - teşekkür ederim. Kullanmak ve Ubuntu deneyiminin bir parçası olmak isteyen geliştiricilere - hoşgeldiniz.


6
Son kontrol QT tamamen ücretsizdir. Daha önce böyle değildi, ama şimdi her şey ücretsiz.
Mario Kamenjak

5
@VassilisGr Qt, bir süredir GPL uyumlu olmuştur (bu, diğer GPL şeyleri kadar ücretsiz kılar). Bununla birlikte, Qt'nin topluluktan bir kod katkısı alması için, bu ödemenin, birisinin ödemesi durumunda, bugün Qt’ya sahip olan şirketin, koda GPL olmayan bir lisans satması için izin veren ikili lisans altında verilmesi gerekir. “Özgürlük Yazılımında olduğu gibi Özgür” ün Stallman tanımında bir sorun değildir (yalnızca ödeme yapmayan ve dolayısıyla GPL'yi kullananlardan yazılım almayı düşündüğümüz sürece ...) Ubuntu, ödeme yapmaz, ve böylece GPL, hangi Linux zaten ... çok iyi.
HostileFork

14

GTK + çözünürlük bağımsızlığını desteklemiyor, Modern mobil cihazlarda ultra yüksek piksel yoğunlukları var. Bir GTK + uygulamasını bir mobil ekranda çalıştırırsanız, tüm kullanıcı arayüzü öğeleri kullanılamaz olacak kadar küçük olacaktır.

Bu, GTK + 'da 2008’den bu yana, “şimdi hi-dpi ölçek desteğine sahibiz - tamamen aynı şey değil, ancak bu hatayı eski durumuna getirecek kadar yakın” yorumuyla kapatılıncaya kadar açık bir hataydı.

GTK + 3 piyasaya sürüldüğünde, projeye çözünürlük bağımsızlığı eklemek için mükemmel bir fırsat vardı, çünkü yine de uyumluluktan kopuyorlardı. Yapmamayı seçtiler ve şimdi onlar için gerçekten çok geç.

On GTK + Yol Haritası işte bu olacak sonra onlar 4.0 sonra ana sürümünü yayınlayacak böylece, çözünürlük bağımsızlık, 4.0 sonra serbest bırakılması için planlanmaktadır. Bu plana sadık kalırlarsa, masaüstü GNU / Linux bile GTK + 'yı terk etmek zorunda kalacak çünkü yüksek DPI masaüstü monitörleri ve dizüstü bilgisayar monitörleri zaten mevcut ve yeni normal olmak üzere.


2

Teknik / pragmatik nedenlerle uğraşmam: Nokia, Trolltech'i satın aldı ve QT'ye çok yatırım yaptı. Hafif ve mobil platforma yönelik yıllarca optimizasyonu var. Nokia'nın şu anki görüşlerine bakılmaksızın, N900, zamanının ilerisindeydi ... ve debian / QT tabanlıydı ... ama pahalıydı. Ancak, kararlar hakkında gerçek bir bilgim yok.


2
QT ayrıca büyük ölçüde daha taşınabilirdir. QT kullanarak bir uygulama oluşturan bir geliştirici için daha fazla patlama, çünkü pek çok işletim sisteminde yerel destek bulacak - Android, Blackberry, Windows Mobile, WebOS. ve tabii ki Mac OS ve Windows. QT ayrıca önemli ölçüde daha fazla katkıda bulunanlardan da faydalanıyor.
mike stewart

1

Ubuntu CTO Matt Zimmerman'in blogu da bilgi vericidir :

Bu ruh haliyle son zamanlarda Qt hakkında düşünüyorum. Ubuntu için uygulamalar geliştirmeyi hızlı, kolay ve acısız yapmak istiyoruz ve Qt, uygulama geliştiricileri için keşfedilmeye değer bir seçenek. Bunu düşünürken, Qt’un güçlü yanlarıyla Ubuntu’daki bazı yeni yönler arasında oldukça fazla bir ortaklık olduğunu fark ettim:

  • Qt, gömülü cihazlarda popüler olması nedeniyle ARM ve x86'da uzun bir kullanım geçmişine sahiptir . 10 yıldan fazla bir süredir ARM üzerinde Qt kullanılarak tüketici ürünleri oluşturulmuştur. Ubuntu ürünlerini neredeyse iki yıldır ARM için kullanılabilir hale getiriyoruz ve 10.10, Freescale, Marvell ve TI'ın referans tahtaları da dahil olmak üzere her zamankinden daha fazla ARM panosunu destekliyor. Qt, en yeni ARM çiplerine fayda sağlamak için ARMv7 optimizasyonları ekliyor. Bunu, OEM'lere yazılım seçiminden ödün vermeden bir donanım seçimi sunmak için yapıyoruz. Qt, bu aynı seçimi uygulama geliştiricileri için de korur.
  • Qt, Windows, MacOS ve daha fazlası için resmi bağlantı noktaları ve Android, iPhone ve WebOS için deneysel topluluk bağlantı noktaları içeren bir platformlar arası uygulama çerçevesidir. Güçlü platformlar arası destek, Qt'nin orijinal prensiplerinden biriydi ve resmi limanların vadesinde gösteriyor. Ubuntu Light, Windows yüklü bilgisayarlara ve Ubuntu One'ın Android ve iPhone'a indirilmesiyle birlikte, diğer platformlarla birlikte çalışabilirliğe ihtiyacımız var. Ayrıca, zaten Windows’u nasıl hedefleyeceğini bilen, Ubuntu kullanıcılarına Qt’yi seçerek de ulaşabilen çok sayıda geliştirici popülasyonu var.
  • Qt, artık yalnızca Windows 7 ve Mac OS X 10.6'da tam olmasına rağmen, çoklu dokunma ve hareketleri (QML dahil) destekleyen, oldukça olgun bir dokunma giriş sistemine sahiptir. Bu arada, Canonical, Qt ve diğer araçların yararı için Linux ve X11 için düşük seviyeli çoklu dokunmalı bir çerçeve geliştirmek için toplulukla birlikte çalışıyor. Bu çabalar sonunda ortada buluşacak.

Genel olarak, Qt'un Ubuntu için (ve şimdi) özellikle de uygulamaları geliştirmek isteyenlere sunabileceği çok şey olduğunu düşünüyorum. Tüm Kubuntu dağıtımından bahsetmek yerine, VLC gibi popüler çapraz platform uygulamalarına güç veriyor. Bu geçen yıl olduğu zaman kaçırdım, ancak Qt şu anda LGPL 2.1 veya GPL 3.0 altında mevcut ve bu da hemen hemen tüm Ubuntu uygulamaları için uygun hale getirmesi gerekiyor. Büyük bir geliştirici topluluğunun yanı sıra güçlü bir ticari desteğe de sahiptir. Elbette, hiçbir geliştiricinin gereksinimlerini karşılayacak tek bir çözüm bulunmuyor ve Ubuntu bu nedenle birden fazla araç kitini ve çerçeveyi desteklemiyor, ancak Qt, ilerideki yol için araç kutumuzda olması gereken harika bir araç gibi görünüyor.

Bu blog gönderisini tartışan bir Ars Technica makalesi bazı görüşler sağlar:

Qt üçüncü taraf geliştiricileri Linux'a getirebilir

Her ne kadar Gtk + hala bir değere sahip olsa ve onu yerli Linux yazılımı oluşturmak için kullanmaya devam etmek için bir takım nedenler olsa da, Qt artık çoklu platformları hedefleyen ISV'ler için bariz bir seçim. Qt, altta yatan platformun doğal görünümüne ve havasına uymayı veya bir hedef cihaza veya form faktörüne en uygun şekilde tamamen kişisel bir kullanıcı arayüzü oluşturmayı son derece kolaylaştırır.

Nokia ve Intel, MeeGo'yu çok çeşitli cihazlara getirdiğinden, bazı büyük ticari yazılım satıcılarını cezbedecek. Bu yazılım şirketlerinin MeeGo'da kullandıkları kodu kullanarak mobil Qt uygulamalarını Linux masaüstüne getirmeleri nispeten kolay olurdu. Qt, bunu kolaylaştırmak için özel olarak tasarlanmıştır. Bu, masaüstü Linux için büyük bir kazanç olacaktır, çünkü başka türlü kullanılamayacak üçüncü taraf uygulamaları getirecektir.

Bazı önde gelen mobil yazılım satıcılarının Nokia'nın araç setini desteklemesi nedeniyle QT'yi çoktan hevesle kucakladıklarını belirtmekte fayda var. Örneğin mobil video akış şirketi Qik, popüler uygulamasının deneysel Qt tabanlı bir limanı üzerinde, MeeGo'ya getirmek amacıyla çalışıyor.

Makalenin yazarı, Gwibber IM uygulamasının yaratıcısıdır, bu nedenle Linux için GUI geliştirme konusunda bazı tecrübeleri vardır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.