it-swarm-tr.com

Neden Qt ile daha fazla masaüstü uygulaması yazılmıyor?

Qt ile yaşadığım deneyimde bildiğim ve anladığım kadarıyla, çok iyi ve öğrenmesi kolay bir kütüphane. Çok iyi tasarlanmış bir API'ye sahiptir ve çapraz platformdur ve bunlar onu çekici kılan birçok özellikten sadece ikisidir. Daha fazla programcının neden Qt kullanmadığını bilmek istiyorum. Buna karşı konuşan bir eksiklik var mı? Hangi özellik diğer kütüphaneleri Qt'den daha iyi yapar? Sorun lisanslama ile ilgili mi?

205
Dehumanizer

Bunun gerçekten bir cevap olmasını istemiyorum, ama bunlar şahsen Qt kullanmama nedenlerim. Bununla ilgili söylenecek çok iyi şeyler var - yani API çoğu zaman çalışıyor ve platformları sorunsuz bir şekilde köprülüyor. Ama Qt kullanmıyorum, çünkü:

  1. Bazı durumlarda, yerel programlar gibi görünmüyor. Tüm platformlar için tek bir kullanıcı arayüzü tasarlamak, çeşitli görsel stil nedenleriyle, makineden makineye taşındığında doğru görünmeyecektir. Örneğin, Mac makinelerde, bölünmüş çubuklar genellikle nispeten kalındır ve düğmeler küçüktür ve simgelerle yuvarlaklaştırılmıştır. Windows makinelerinde, bölünmüş çubuklar genellikle dardır ve düğmeler daha kare tasarımlarla daha metinseldir. Her platform için bir kullanıcı arayüzü yazabilmeniz, çoğu uygulama için yapmanız gerektiği anlamına gelmez.
  2. Qt bir C++ kütüphanesi değildir. Ayrı bir derleme adımı gerektirir, bu da derleme işlemini diğer kitaplıkların çoğuna kıyasla çok daha karmaşık hale getirir.
  3. (2) sonucunda, C++ IDE'leri ve araçları Qt ifadelerini hata olarak işaretleyebilir, çünkü Qt'ın özelliklerini anlamıyorlar. Bu neredeyse QtCreator veya vim gibi bir metin editörü kullanımını zorlar.
  4. Qt, derlemeden önce kullandığınız herhangi bir makineye hazır ve önceden kurulmuş olması gereken büyük miktarda kaynaktır. Bu, bir yapı ortamının kurulmasını çok daha sıkıcı hale getirebilir.
  5. Yalnızca LGPL altında kullanılabilir, bu da daha kısıtlayıcı veya daha az kısıtlayıcı bir lisans altında yayınlanması gerektiğinde tek ikili dağıtımın kullanılmasını zorlaştırır.
  6. Benzer şekilde yazılmış "düz ol 'yerel uygulamalar" (KDE için yazılmış ders uygulamaları hariç) ile karşılaştırıldığında son derece büyük derlenmiş ikili dosyalar üretir.
178
Billy ONeal

İnsanların dediği gibi, her araç her probleme ve duruma uyar ...

Ancak C++ programcısıysanız, Qt sizin çerçevenizdir. Rakip yok.

Karmaşık bir tıbbi görüntüleme ticari uygulaması geliştiriyoruz ve Qt devam ediyor.

İnsanların bu konuda söyledikleri 'eksilerini' söylemiyorum, ama Qt'yi uzun zamandır denemediklerini hissediyorum (her yeni versiyonda sürekli olarak gelişiyor ...) Ve çoğunlukla dikkat ettikleri tüm yorum sorunları bir sorun değildir.

UI platformunda tutarsızlık: Yalnızca, özelleştirme veya özel resim olmadan UI widget'larını 'oldukları gibi' kullanırsanız.

Qt önişlemci aşırı yüklemesi: Yalnızca gerçekten gerekli olmadığında sinyal yuvası mekanizmasını veya QObject mirasını kötüye kullanırsanız.

Bu arada, hala C # .NET'te uygulamalar yazıyoruz ve uzun süredir yapıyoruz. Bence çok fazla perspektifim var.

Dediğim gibi, her durum için her araç,

ancak Qt şüphesiz tutarlı ve kullanışlı bir çerçevedir.

116
Inigo

Qt hakkında sevmediğim her şeyden, şablonlarla iyi oynamaması beni en çok rahatsız ediyor. Bunu yapamazsın:

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

Ayrıca önişlemci ile iyi oynamıyor. Bunu yapamazsın:

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

Bu, bir sinyale yanıt veren her şeyin bir Q_OBJECT olması gerektiğiyle karıştırıldığında, Qt'nin bir C++ programcısı için çalışmasını zorlaştırır. İnsanlar Java veya Python) tarzı programlama aslında daha iyi olabilirdi.

Aslında araştırma yapmak ve tip güvenliğini geri kazanmak ve herhangi bir fonksiyon nesnesine bir Qt sinyali bağlamak için bir yol bulmak için çok zaman ve çaba harcadım: http://crazyeddiecpp.blogspot.com/2011/01/quest-for -sane-sinyaller-in-qt-adım 1.html

Orada yapmak istediğim şey Qt moc tarafından imkansız yanında yapılan temel, günlük C++ geliştirme ... aslında, eğer şimdi, şimdi tamamen gereksizdir.

Açıkçası, ben onunla sıkışmış çünkü otomatik UI testi yapmak istiyorsanız, Qt hemen hemen MFC kısa şehirdeki tek oyun ... yani 1980 (bu bok gerçekten zor çalışır) berbat. Bazıları WX diyebilir, ancak daha da ciddi sorunları var. GTKmm benim ilk tercihim olurdu, ancak tüm sahibi çekildiğinden ve erişilebilirlik yapmadığından ... endüstri standardı test yazılımı tarafından yönlendirilemez. Qt bu konuda yeterince zor ( erişilebilirlik eklentisini değiştirdiğinizde zar zor çalışıyor).

37
Edward Strange

Qt kullanmamanın bir nedeni, Windows gibi yalnızca bir mimari için yazıyorsanız, C # /. NET (veya Mac'te Cocoa) kullanmak isteyebilirsiniz, çünkü bunlar her zaman en son zillerden yararlanabileceklerdir. - işletim sistemi ıslık.

Platformlar arası uygulamalar yazıyorsanız, o zaman Java (yani bir "Java Shop" da çalışıyorsunuz) gibi başka bir teknolojiye zaten çok fazla hak kazanmış olabilirsiniz. dile özgü API'ler gibi geliştirdiğiniz ekosistem tarafından kullanılabilir. Bu gibi durumlarda, teknolojilerin sayısını en aza indirmek faydalı olabilir.

Düşünebileceğim üçüncü bir neden, Qt'nin C++ temelli olması ve C++ 'ın programlanması nispeten zor/tehlikeli bir dildir. Bence bu profesyoneller için bir dil. En iyi performansa sahip olmanız ve titiz olabilmeniz gerekiyorsa, C++ muhtemelen şehirdeki en iyi oyun. Aslında, işler kapsam dışında kalacak şekilde ayarladıysanız, Qt birçok bellek yönetimi sorununu iyileştirir. Ayrıca, Qt kendisi kötü pis ++ sorunlarının bir çok kullanıcı yalıtım iyi bir iş yapar. Her dilin ve çerçevenin artıları ve eksileri vardır. Hız, Kalite ve Fiyat (genellikle iki tane seçebilirsiniz), genellikle diners sık görülen addage tarafından özetlenebilir çok, çok karmaşık bir konudur.

Kurallar soruyu cevaplamaya odaklanmam gerektiğini söylese de, Billy ONeal'in ortaya koyduğu bazı sorunları reddetmek istiyorum, bence Qt kullanmamanın yaygın olarak belirtilen nedenlerini özetleyen iyi bir iş var:

  1. Qt aslında bir C++ kütüphanesi/framework/header dosyasıdır. Diğer şeylerin yanı sıra sinyalleri ve yuvaları etkinleştiren bir makro işlemci (moc) tarafından artırılmış. Ek makro komutlarını (Q_OBJECT gibi) dönüştürerek sınıfların içgözlemini ve C++ 'a Objective-C işlevselliği eklemek olarak düşünebileceğiniz diğer tüm güzellikleri dönüştürür. Bu saflık eksikliğinden rahatsız olacak C++ hakkında yeterli bilgiye sahipseniz, yani bir profesyonelseniz, 1) Q_OBJECT ve ilkini kullanmayın veya 2) bunu yaptığına minnettar olun ve çok sınırlı köşe vakaları etrafında programlayın burada bir soruna neden olur. "Sinyaller ve yuvalar için Boost kullanın!" Diyen insanlar için. o zaman bir "problemi" diğeriyle değiştirdiğinizi onaylıyorum. Boost çok büyük ve kötü belgeleme, korkunç API ve platformlar arası dehşet gibi genel olarak belirtilen sorunları var (gcc 3.3 gibi eski derleyicileri ve AIX gibi büyük demir derleyicilerini düşünün).

  2. Editör desteği için bu da 1'den geliyor, biraz katılıyorum. Aslında, Qt Creator, Qt şeyler kullanmasanız bile en iyi grafiksel C++ editörü IMHO'dur. Birçok profesyonel programcı emacs ve vim kullanır. Ayrıca, Eclipse ek sözdizimini işler. Bu nedenle, Qt makrolarıyla (Q_OBJECT) veya sinyal/yuva eklemelerinde sorun yoktur. Muhtemelen bu makroları Visual Studio'da bulamazsınız, çünkü (kabul ediyorum) C++ 'a eklemelerdir. Ama genel olarak, C # /. NET millet, kendi mülkiyet teknikleri ile kaplı birçok işlevselliğe sahip oldukları için zaten Qt kullanmayacaklar.

  3. Qt kaynağının boyutuna gelince, bir gecede derlendiği sürece kimin umurunda? Çift çekirdekli Macbook'umda Qt 4'ü "geceden az" olarak derledim. Umarım bu, belirli bir teknolojiyi kullanma veya kullanma kararınızı yönlendiren şey değildir. Bu gerçekten bir sorunsa, Mac, Linux ve Windows için önceden derlenmiş SDK'ları Qt web sitesinden indirebilirsiniz.

  4. Lisanslama üç seçenekte mevcuttur: 1) Qt KENDISINI değiştirmek istemiyorsanız ve Qt ve atfetmeye istekli değil (marka ve imaj için çok önemli olabilir!) 2) GPL ve 3) LGPL. Evet, statik bağlantı ile ilgili sorunlar var (tüm Qt'yi ikili dosyaya yuvarlama) - ama bunun daha fazla olduğunu düşünüyorum çünkü biri içeri bakamaz ve Qt (atıf!) Kullandığınızı fark edemez. Digia'dan özel bir lisans satın almaya çalıştım ve bana "ne yaptığınız için gerçekten ihtiyacınız yok" dediler. Vay. Lisans satma işinde olan bir şirketten.

  5. İkili/paketin boyutu, Qt öğelerini sahip olmayan kişilere dağıtmanız gerektiğidir: Windows zaten var mı? Visual Studio veya çalışma zamanı yüklemeniz gerekir. Mac zaten muazzam Kakao ile geliyor ve dinamik olarak bağlanabilir. Çok fazla dağıtım yapmama rağmen, ~ 50 megabayt statik dosyayı (UPX gibi ikili striptizci/sıkıştırma yardımcı programlarından bazılarıyla daha da küçültebilirim) dağıtmakla ilgili çok fazla sorun bulamadım. Bunu yapmak için yeterince umurumda değil, ancak bant genişliği hiç bir sorun olsaydı, derleme komut dosyama UPX adımı eklerdim.

  6. "Doğal Bakış ve Hissi" ne tanımlar? Sanırım "çoğu" Mac'in birleşik görünüm ve izlenime en yakın olduğu konusunda hemfikir. Ama burada oturuyorum, Safari, iTunes, Diyafram, Final Cut Pro, Pages, vs.'ye bakıyorum ve işletim sistemi satıcısı tarafından yapılmış olmalarına rağmen benzer görünmüyorlar. "Hissediyorum" yönü daha alakalı olduğunu düşünüyorum: widget stil, duyarlılık, vb. Eğer duyarlılık önemsiyorsanız, burada Java yerine C++ kullanmak için iyi bir neden, ya da diğer son derece dinamik bir dil. (Amaç C de sallanıyor, ama Qt hakkındaki efsaneleri ortadan kaldırmaya çalışıyorum)

Özetle, bu karmaşık bir konudur. Ama şunu belirtmek isterim ki, “Qt kullanmamanın” daha az nedeni olduğunu düşünüyorum, çünkü biri mitlere ve on yıllık güncel bilgilere dayanarak düşünebilir.

28
Eric Brown

Bazıları lisanslama. Bazı lisans geçmişi için https://en.wikipedia.org/wiki/Qt_ (yazılım) #Licensing adresine bakın. 2000 yılına kadar, açık kaynaklara büyük önem veren insanlar Qt kullanmıyordu. Dönemi. (Bu aslında, Gnome'un gelişimi için orijinal motivasyondu.) 2005 yılına kadar Windows için ücretsiz yazılım yayınlamak isteyen insanlar Qt kullanmıyordu. O tarihten sonra bile, GPL dışında bir şey altında özgür yazılım isteyenler, Qt kullanma seçeneğine sahip değildi. Bu nedenle, bu tarihlerden daha eski olan herhangi bir özgür yazılım projesi Qt. Ve elbette, tescilli kod yazan insanlar ayrıcalık için ödemek zorunda kaldı.

Ayrıca, diğer seçeneklerin sıkıntısı varmış gibi değil. Örneğin WxWidgets , GTK + ve Tk açık kaynaklı, platformlar arası araç takımlarıdır.

Ayrıca, uzun bir süre Windows masaüstünde o kadar baskındı ki, bir çok yazılım sadece Windows üzerinde çalışacak içerikti. Microsoft araç zincirini kurarsanız, Microsoft'un tescilli eşyalarını kullanmak, başka bir şey hakkında endişelenmekten daha kolaydır ve birçok programcı bunu yaptı.

26
btilly

Yukarıda tartışılan nedenlerin neredeyse hepsine katılıyorum, ancak buradaki birçok insan beraberinde getirdiği ekstra yük nedeniyle Qt'yi kullanmayacaklarını söyledi. Buna katılmıyorum çünkü bugün en yaygın diller (Java, C # ve Python) oldukça fazla yük taşıyorlar.

İkincisi, Qt, C++ ile programlamayı o kadar kolay ve basit hale getirir ki kullandığı ekstra kaynakları telafi eder. Yazabilme kolaylığı nedeniyle standart C++ yerine Qt ile yazılmış oldukça az sayıda konsol uygulamasına rastladım.

Qt'nin verimliliğinin C/C++ 'dan daha yüksek olduğunu ancak Python gibi dillerden daha az olduğunu söyleyebilirim.

14
W.K.S

Bu gerçekten bir alev savaşı başlatmak için bir girişim değil, sadece bazı noktalara değinmek istedim.

Muhtemelen Qt'nin daha yaygın kullanılmamasının gerçek nedeni, C++ ve daha az kişinin masaüstü uygulamaları için c ++ kullanmasıdır.

Qt bir C++ kütüphanesi değildir. Ayrı bir derleme adımı gerektirir, bu da derleme işlemini diğer kitaplıkların çoğuna kıyasla çok daha karmaşık hale getirir.

Visual studio için vs-addin bunu otomatik olarak Qt'nin kendi komut satırı oluşturma işlemi yapar. MFC için iletişim kutuları oluşturmak için kullanılan kaynak derleyici de ayrı bir adımdır, ancak yine de c ++.

Qt, derlemeden önce kullandığınız herhangi bir makineye hazır ve önceden kurulmuş olması gereken büyük miktarda kaynaktır. Bu, bir yapı ortamının kurulmasını çok daha sıkıcı hale getirebilir.

Visual Studio'nun her sürümü için ikili bir indirme vardır ve kaynaktan derleme tek bir komuttur. SDK kaynak boyutunun bugünlerde çok fazla bir şey olduğunu görmüyorum. Visual Studio artık seçmenize ve seçmenize izin vermek yerine tüm C++ kütüphanelerini yükler, sonuç olarak derleyicinin yükleme boyutu> 1 Gb'dir.

Yalnızca LGPL altında kullanılabilir, bu da daha kısıtlayıcı veya daha az kısıtlayıcı bir lisans altında yayınlanması gerektiğinde tek ikili dağıtımın kullanılmasını zorlaştırır.

LGPL sadece lib için geçerlidir, kodunuzu etkilemez. Evet, (ödeme yapmadıkça) tek bir ikili yerine DLL göndermeniz gerektiği anlamına gelir, ancak bir Java çalışma zamanı veya küçük bir kullanım için .Net güncellemesi indirmeniz gereken bir dünyada) Tek bir ABI'ye sahip platformlarda da daha az sorun var, böylece diğer Qt uygulamaları kütüphaneleri paylaşabilir.

Bazı durumlarda, yerel programlar gibi görünmüyor. Tüm platformlar için tek bir kullanıcı arayüzü tasarlamak, çeşitli görsel stil nedenleriyle, makineden makineye taşındığında doğru görünmeyecektir.

Yerel widget'ları ve temaları kullanması gerekiyor. Genelde teknik uygulamalar yaptığımı itiraf etmeliyim ki kullanıcılarım stil konusunda fazla endişe duymuyorlar. Özellikle pencerelerde, akıllı telefon widget'ı olarak her şeyin tarzına sahip olmanın yeni modası, zaten daha az ve daha az standart olduğu anlamına gelir.

11
Martin Beckett

Nedeni basit: tüm ana diller için iyi bağları yoktur ve sihirli bir şekilde her zaman eldeki iş için uygun değildir.

İş için doğru aracı kullanın. Basit bir komut satırı uygulaması yazıyorsam, bunu neden sadece Qt ile şişireyim ki?

Daha genel bir cevap olarak (ki burada alakalı olduğum için verebilirim), bazı programcılar hiçbir zaman bir şans vermedi ve kullanmaya karar verdiler. Bazı durumlarda, programlayıcının buna hiç ihtiyaç duymadığı ve içine bakma dışında özel bir nedeni yoktur.

Qt gibi çerçeveler, ürününüzün tüm platformlarda aynı görünmesi ile tüm platformlarda aynı görünmesi ile ilgilendiğinizde uygundur. Bugünlerde bu tür uygulamalar web tabanlı teknolojilere geçiyor.

5
Caleb

Qt ile çalışmak için güzel bir çerçeve olduğunu kabul ediyorum. Yine de, bununla ilgili bir takım sorunlar var:

  1. Gerçekten düşük seviyeli bir dil olan C++ ile yazılmıştır. Sadece C++ olması, her Qt programcısını diğer dillerde yazılmış olan Frameworks'lere kıyasla önemli ölçüde daha az üretken hale getirecektir. Bir GUI geliştirme dili olarak C++ ile ana sığır eti, otomatik hafıza yönetimi kavramının yanında olmaması, bu da geliştirme sürecini hatalara daha yatkın hale getiriyor. Bu, hata ayıklamayı çok daha zorlaştıran içgözlemli değildir. Diğer büyük GUI araç takımlarının çoğunda bazı otomatik bellek yönetimi ve içgözleme fikri vardır.
  2. Her çapraz platform araç takımı, desteklenen tüm platformların en az ortak paydasını uygulayabileceği sorunundan muzdariptir. Bu ve farklı platformlardaki farklı kullanıcı arayüzü yönergeleri, platformlar arası GUI'lerin bir bütün olarak arzu edilebilirliğini çok sorguluyor.
  3. Qt, tüm kullanıcı arayüzünüzü kodlamaya odaklanmıştır. Kullanıcı arayüzünüzün bazı bölümlerini oluşturmak için QtDesigner'ı kullanabilseniz bile, (Cocoa/Obj-C) Arabirimine kıyasla ciddi şekilde eksik Oluşturucu veya .Net araçları.
  4. Qt çok sayıda düşük seviyeli uygulama işlevselliği içermesine rağmen, belirli bir platform için el yapımı bir çerçeveye sahip olmakla kıyaslanamaz. Hem Windows hem de OSX için yerel işletim sistemi kitaplıkları Qt uygulamalarından önemli ölçüde daha güçlüdür. (Ses çerçevelerini, düşük düzeyli dosya sistemine erişimi vb. Düşünün.)

Bununla birlikte, hızlı uygulama prototiplemesi veya şirket içi uygulamalar için PyQt kullanmayı seviyorum. Tüm kodlamayı yapmak için Python kullanmak C++ ile ilgili endişeleri azaltır ve aslında Qt'yi çok hoş bir yer yapar.


Bazı yorumlara yanıt olarak düzenleyin:

Qt'nin C++ ile yazılması hakkında yazdığımda, Qt'un kendisi hakkında çok fazla şikayetçi değildim, ama içinde yaşadığı çevre hakkında daha fazla şikayet ettim. Qt'un kendi kaynaklarını çok iyi yönettiği doğrudur, ancak GUI ile ilgili tüm not-Qt kodu C++ ile de yazılmalıdır. Orada bile, Qt birçok Nice aracı sağlar, ancak nihayetinde, bu seviyede C++ ile uğraşmanız gerekir. Qt, C++ 'ı katlanılabilir kılar, ancak yine de C++' dır.

İçgözlem gelince, demek istediğim şu: Hata ayıklamak için en zor durumlar, düşündüğünüz gibi davranmayan bir nesneye bir işaretçi olduğundadır. C++ ile, hata ayıklayıcı bu nesnenin içine biraz bakabilir (eğer thwt noktasında tür bilgisi varsa), ancak bu her zaman işe yaramaz. Öte yandan, aynı durumda Kakao alın. Cocoa/Obj-C'de, hata ayıklayıcıdaki bir nesneye mesaj ('çağrı işlevleri') gönderebilirsiniz. Nesnelerin durumunu değiştirebilir, öznitelikleri için sorgulayabilir, türünü ve işlev adlarını sorabilirsiniz ... Bu hata ayıklamayı çok daha kolay hale getirebilir. Qt/C++ 'da buna yakın bir şey yok.

4
bastibe

kendi düşünceme göre, C++ programlama öğrenmek karmaşıklıklarını gizleyen diğer dillere düşmekten daha basittir ve programcı arka planda gerçekten ne olduğunu bilmiyor. Qt ise C++ 'a göre bazı faydalar ekleyerek onu doğal C++' dan daha yüksek bir seviyeye getirir. Bu nedenle Qt C++, aynı şekilde düşük düzeyli veya yüksek düzeyli görevler geliştirmek isteyenler için harika bir çerçevedir. C++ (bazı uygulamalarla) karmaşık ve basit bir dildir. Onunla meydan okumak istemeyenler için karmaşık, sevenler için basit. Karmaşık olduğu için bırakmayın!

4
user100691

En önemli ama bahsedilmeyen şey. Büyük projede bir şey çok fazla soruna ve gerekli olmayan koda neden olur. Qt 'un sinyal yuvası mekanizmaları yetersizdir. Qt widget'ları olay basit widget'ları için gerekli sinyalleri sağlamaz. Örneğin onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus vb. İçin sinyal ayarlayamazsınız. QTreeWidget gibi en karmaşık widget bile bir veya iki ultra basit yararsız sinyal sağlar.

Evet, olayları kullanabilirsiniz AMA !!! özel etkinliğe sahip her widget için yeni sınıf oluşturdunuz. Bu büyük bir verimlilik kaybıdır;

  • Her özelleştirilmiş widget nesnesi olayını yeniden yazdınız, küçük değişiklikler var.
  • Qt Designer'ın tüm eşyalarını kaybedersiniz. Her widget'ı özel etkinliklerle tanıtmanız gerekir.
  • Proje büyüdü ve bakımı zorlaştı.
  • Bu yüzden qt'dan hoşlanmamaya başladınız. Ve .net'in delegelere nasıl sağladığını, sinyal yuvasından nasıl daha iyi olduğunu, .net bileşenlerinin (widget'ların) hayal edebileceğiniz her olayı nasıl sağladığını konuşmaya başlayın. Ve benzeri.

Üniversitemden biri, bazı combo kutusu widget'ları için yeni bir açılan kutu sınıfı yazdı çünkü bazı sinyalsiz olayları kullanmak zorunda kaldı. Gerçek hikaye...

Ancak, Qt çıkışlar ve inekler ile şimdiye kadarki en iyi C++ UI çerçevesi.

3
Obrix

Qt'yi gerçekten seviyorum, ancak birçok uygulama için biraz ağır. Bazen bu karmaşıklık düzeyine ihtiyacınız olmaz. Bazen Qt'nin tüm yükü olmadan basit bir şeye ihtiyacınız vardır. Her uygulamanın olay güdümlü olması gerekmez ve C++ makul bir şablon kümesi sağlar. Boost başka bir çok iyi set sağlar ve QT'nin yaptığı birçok düşük seviyeli işlevselliği (dosya, soket, yönetilen işaretçiler vb.) İçerir.

Diğer uygulamalarda GPL, LGPL veya Qt'nin ticari lisansı ile Nice oynamayan lisans gereksinimleri vardır. GPL ticari yazılımlar için uygun değildir. LGPL, statik olarak bağlı yazılımlar için uygun değildir ve ticari lisans para gerektirir - birçoğunun ödemek istemediği bir şey.

Bazılarının Qt gibi karmaşık kütüphanelere izin vermeyen güvenlik veya kararlılık hususları vardır.

Kaynaklarınızı önceden işlemek için moc çalıştırmanız gerekir. Bu büyük bir sorun değil, ancak yeni kullanıcı için göz korkutucu olabilir. Pek çok programcı qmake'yi Qt ile kullanmanız için need olduğunu düşünüyor, ama bu yanlış bir isim. Qt'yi diğer yapı sistemlerine kolayca takmak mümkündür.

Bazı hedefler çok bellek veya CPU kısıtlıdır.

İçinde platforma özgü bazı yakalamalar var. Bu gotchaların çoğu belgelenmemiş. Yeterince büyük bir uygulama oluşturun ve bunlarla karşılaşacaksınız ve neler olduğunu merak edeceksiniz (sorumluluk reddi, Qt'yi en son öfke olarak kullandığım süre 18 aydan fazlaydı, bu yüzden iyileşmiş olabilir).

Sadece C++. Diğer dil bağlamaları vardır, ancak Qt için istediğiniz işlevselliği gizleme veya zayıf bir şekilde ortaya koyma eğilimindedirler.

Qt kullanmamak için birçok neden var, bu yüzden alternatifler var. Sahip olduğunuz tek şey bir çekiçse, her sorun bir çivi gibi görünecektir.

3
Adam Hawes

Asıl sebep teknik değildir.

İnsanlar farklı oluyor. Onların seçimleri de öyle. Tekdüzelik, insani bir özellik değildir.

2
mouviciel