Neden daha fazla masaüstü uygulaması Qt ile yazılmış değil? [kapalı]

Qt ile olan deneyimimde bildiğim ve anladığım kadarıyla kütüphane öğrenmek çok iyi ve kolay. Çok iyi tasarlanmış bir API'ye sahiptir ve çapraz platformdur ve bunlar onu çekici kılan özelliklerden sadece ikisidir. Neden daha fazla programcının Qt kullanmadığını bilmek istiyorum. Buna karşı çıkan bir eksiklik var mı? Hangi kütüphaneler diğer kütüphaneleri Qt'dan daha iyi kılar? Sorun lisansla ilgili mi?

Bunun kesin bir cevap olması niyetinde değilim, ancak kişisel olarak Qt kullanmamamın nedenleri bunlar. Bununla ilgili söylenecek çok şey var - yani API çoğu zaman çalışır ve platformları sorunsuz bir şekilde köprüler. Fakat Qt kullanmıyorum, çünkü:

1. Bazı durumlarda, yerel programların göründüğü gibi görünmüyor. Tüm platformlar için doğal olarak tek bir UI tasarlamak, çeşitli görsel şekillendirme nedenleriyle makineden makineye taşınırken doğru görünmeyecektir. Örneğin, Mac makinelerinde, ayırma çubukları genellikle nispeten kalındır ve düğmeler küçüktür ve simgelerle yuvarlanmıştır. Windows makinelerde, ayırma çubukları genellikle dardır ve düğmeler daha fazla kare tasarımla daha metinseldir. Sadece her platform için bir UI yazabildiğiniz için çoğu uygulama için yapmanız gereken anlamına gelmez.
2. Qt, bir C ++ kütüphanesi değildir. Yapı sürecini diğer kütüphanelerin çoğuyla karşılaştırıldığında daha karmaşık hale getiren ayrı bir derleme adımı gerektirir.
3. (2) 'nin bir sonucu olarak, C ++ IDE'ler ve araçları Qt ifadelerini hata olarak işaretleyebilirler, çünkü Qt'nin özelliklerini anlamıyorlar. Bu neredeyse QtCreator veya bir metin editörü gibi sadece editör kullanımını zorlar vim.
4. Qt, derlemeden önce kullandığınız herhangi bir makinede bulunması ve önceden yüklenmiş olması gereken büyük miktarda bir kaynaktır. Bu, inşaat ortamı oluşturmayı çok daha sıkıcı hale getirebilir.
5. Yalnızca LGPL'de bulunur; bu, daha kısıtlayıcı veya daha az kısıtlayıcı bir lisans altında yayınlanması gerektiğinde tekli ikili dağıtımı kullanmayı 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.

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

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

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

İnsanların bu konuda söyledikleri 'eksilerin' yanlış olduğunu söylemiyorum, ancak uzun bir süredir Qt'yu denemediklerini hissediyorum (her yeni versiyonda sürekli olarak iyileştiriliyor ...) Ve, çoğunlukla Dikkatli olursanız, yorumladıkları tüm konular sorun olmaz.

UI platformu tutarsızlığı: yalnızca UI widget'larını 'olduğu gibi' kullanırsanız, özelleştirmeden veya özel sanat olmadan.

Qt önişlemci aşırı yüklemesi: Sadece gerçekten ihtiyaç olmadığında sinyal yuvası mekanizmasını veya QObject devralmasını kötüye kullanıyorsanız.

Bu arada, biz hala uygulamaları C #. NET'te yazıyoruz ve uzun zamandır yapıyoruz. Bu yüzden bakış açısına sahip olduğumu düşünüyorum.

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

ama Qt şüphesiz tutarlı ve faydalı bir çerçevedir.

Qt ile ilgili sevmediğim her şey arasında, şablonlarla iyi oynamama durumu 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şlemciyle 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ği gerçeğiyle karıştırıldığında, Qt'nin bir C ++ programcısı için çalışmasını zorlaştırır. Java ya da Python tarzı programlamaya alışkın olan insanlar muhtemelen daha iyi.

Aslında, geri dönüş sağlamanın ve herhangi bir functor nesnesine Qt sinyalini bağlamanın bir yolunu araştırmak ve geliştirmek için çok zaman ve çaba harcadım: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-qt adımlı-1.html

Orada yapmak istediğim tür, temelde, gerçekten de olsa, bugünlerde tamamen gereksiz olan Qt moc tarafından imkânsız olarak yapılan, her gün C ++ gelişimi.

Açıkçası, onunla sıkışmışım çünkü otomatik UI testi yapmak istiyorsanız, Qt şehirdeki MFC'den kısa olan tek oyundur ... ki bu çok 1980 (bu çok zor işte çok işe yaramaz). Bazıları WX diyebilir ama daha ciddi problemleri var. GTKmm benim ilk tercihim olacaktı, ancak sahibi tamamen çizildi ve erişilebilirlik yapmadığı için endüstri standardı test yazılımı tarafından kullanılamaz. Qt bu konuda yeterince zordur ( erişilebilirlik eklentisini değiştirdiğinizde zorlukla çalışır).

Qt kullanmamanın bir nedeni, Windows gibi yalnızca bir mimari için yazıyorsanız, C # /. NET (veya Mac’teki Kakao) kullanmak isteyebilirsiniz, çünkü her zaman en son çanlardan yararlanabileceklerdir. - İşletim sisteminin ihbarları.

Platformlar arası uygulamalar yazıyorsanız, Java gibi başka bir teknolojiye zaten katıldınız (yani bir "Java Mağazasında" çalışıyorsunuz). Teknoloji seçiminiz, dile özgü API'ler gibi geliştirmekte olduğunuz ekosistem tarafından belirlenebilir. Bu tür durumlarda, teknolojilerin sayısının en aza indirilmesi faydalı olabilir.

Aklıma gelebilecek üçüncü bir neden ise, Qt'nin C ++ 'a dayanıyor olması ve C ++' ın programlanması nispeten zor / tehlikeli bir dildir. Profesyoneller için bir dil olduğunu düşünüyorum. En yüksek performansa ihtiyacınız varsa ve titiz davranabiliyorsanız, C ++ muhtemelen şehirdeki en iyi oyundur. Aslında, Qt, kapsam dışında kalmaya karar verirseniz, bellek yönetimi sorunlarının çoğunu iyileştirir. Ayrıca, Qt'nin kendisi, kullanıcıyı kötü C ++ sorunlarının çoğundan yalıtmak için iyi bir iş çıkarır. Her dilin ve çerçevenin avantajları ve dezavantajları vardır. Genellikle, akşam yemeklerinde sıkça görülen advayla özetlenebilir, çok, çok karmaşık bir konudur: Hız, Kalite ve Fiyat (ancak sadece iki tane seçebilirsiniz).

Her ne kadar kurallar soruyu cevaplamaya odaklanmam gerektiğini söylese de, Billy ONeal tarafından ortaya konan sorunların bir kısmını tekrarlamak isterim.

1. Qt gerçekten bir C ++ kütüphanesi / framework / başlık dosyalarıdır. Bu edilir artarDiğer birçok şeyin yanı sıra sinyalleri ve slotları etkinleştiren bir makro işlemci (moc) ile. Ek makro komutlarını (örneğin, Q_OBJECT gibi) dönüştürür, böylece sınıfların iç gözlemine ve C ++ 'a Objective-C işlevselliği ekleyebileceğini düşünebileceğiniz her türlü diğer özelliğe sahip olmasını sağlar. Eğer C ++ 'nın bu saflık eksikliğinden rahatsız olması için yeterince bilginiz varsa, yani bir profesyonel iseniz, o zaman 1) Q_OBJECT ve ilkini kullanmayın ya da 2) bunun için minnettar olun ve çok sınırlı köşe vakalarını programlayın bu bir soruna neden olur. "Sinyaller ve yuvalar için Boost kullanın!" Diyen kişiler için o zaman bir "problem" i diğeriyle değiştirdiğinizi hatırlatırım. Takviye çok büyük ve kötü belgeleme, korkunç API ve platformlar arası korku gibi sıkça anılan sorunları var (gcc 3 gibi eski derleyicileri düşünün).

2. Editör desteği için bu da 1'den başlıyor, biraz katılıyorum. Aslında, Qt Oluşturan QH malzeme kullanmasanız bile, IMHO en iyi grafiksel C ++ editörüdür. Birçok profesyonel programcı emac ve vim kullanır. Ayrıca, Eclipse'in ek sözdizimini üstlendiğini düşünüyorum. Bu nedenle, Qt makrolarında (Q_OBJECT) veya sinyal / yuva eklerinde sorun yoktur. Muhtemelen bu makroları Visual Studio'da bulamayacaksınız, çünkü (katılıyorum) onlar C ++ 'a eklenmişlerdir. Ancak, C # /. NET millet, kendi özel teknikleri ile kapsanan birçok işlevselliğe sahip oldukları için Qt kullanmayacak.

3. Qt kaynağının boyutuna gelince, bir gecede derlendiği sürece kimin umurunda? Qt 4'ü çift çekirdekli Macbook'umda "bir geceden az" olarak derledim. Umarım bu, belirli bir teknolojiyi kullanmaya ya da kullanmamaya karar vermenizin sebebi değildir. Bu gerçekten bir sorunsa, Mac, Linux ve Windows için önceden derlenmiş SDK'leri Qt web sitesinden indirebilirsiniz.

4. Lisanslama, üç farklı seçeneğe sahiptir: 1) QT ITSELF’i değiştirmek ve paylaşmamak ya da Qt kullanıyor olmanız ve atıfta bulunmaya istekli olmamanız durumunda paylaşma ya da gizleme (marka ve imaj için çok önemli olabilir!) 2 ) GPL ve 3) LGPL. Evet, statik bağlantı ile ilgili sorunlar var (Qt'nin tümünü ikiliye yuvarlama) - ama bence daha fazlası, birinin içine göz atamadığı ve Qt (nitelik!) Kullandığınızı fark edemediği için. Digia'dan tescilli bir lisans almaya çalıştım ve bana "ne yaptığın için gerçekten ihtiyacın olmadığını" söylediler. Vay. Lisans satışı yapan bir işten.

5. İkili / paketin boyutu, Qt malzemelerini sahip olmayan kişilere dağıtmanız gerektiği içindir: Windows zaten var mı? Visual Studio şeyler veya çalışma zamanı yüklemeniz gerekir. Mac zaten muazzam Kakao ile birlikte geliyor ve dinamik olarak bağlanabilir. Çok fazla dağıtım yapmamama rağmen ~ 50 megabayt statik dosyayı dağıtma konusunda fazla sorun bulamadım (ki bu da UPX gibi bazı ikili striptizci / sıkıştırma araçlarıyla daha da küçültebilirim). Bunu yapacak kadar umurumda değil, ama eğer bant genişliği bir sorun olsaydı, derleme betiğime UPX adımı eklerdim.

6. "Doğal Görünüm ve Hissi" ne tanımlar? Bence "çoğu", Mac'in birleşik görünüm ve hislere en yakın olduğu konusunda hemfikir olur. Ancak burada oturup Safari, iTunes, Diyafram, Final Cut Pro, Pages vb. Sayfalarına bakıyorum ve işletim sistemi sağlayıcısı tarafından yapılmış olmalarına rağmen hiçbir şeye benzemiyorlar. Bence "hissetme" yönü daha alakalı: Widget stilleri, yanıt verebilirlik, vs. Yanıt verebilirliği önemsiyorsanız, burada Java yerine C ++ ya da diğer oldukça dinamik bir dil kullanmak için iyi bir neden. (Amaç C de kayalar, ancak Qt ile ilgili mitleri ortadan kaldırmaya çalışıyorum)

Özet olarak, bu karmaşık bir konudur. Ancak, efsanelere ve on yıllık güncel bilgilere dayanarak düşünebileceği gibi “Qt” kullanmamanın daha az neden olduğunu düşündüğümü belirtmek isterim.

Bazıları lisans veriyor. Bkz https://en.wikipedia.org/wiki/Qt_(software)#Licensing lisans tarihinin bazıları için. 2000 yılına kadar açık kaynaklara önem veren insanlar Qt kullanmamışlardı. Dönemi. (Bu aslında Gnome'un geliştirilmesinde asıl motivasyondu.) 2005 yılına kadar, Windows için özgür yazılımları serbest bırakmak isteyen insanlar Qt kullanmıyorlardı. Bu tarihten sonra bile, GPL dışında bir yazılım altında özgür yazılım isteyen insanlar, sadece Qt kullanma seçeneğine sahip değildi. Bu nedenle, bu tarihten daha eski herhangi bir özgür yazılım projesi Qt kullanamadı. Ve elbette, özel kod yazan insanlar ayrıcalık için para ödemek zorunda kaldı.

Ayrıca, başka seçeneklerin bir sıkıntısı varmış gibi görünmüyor. Örneğin , WxWidgets , GTK + ve Tk hepsi açık kaynaklı, çapraz platform araç takımlarıdır.

Üstelik uzun süredir Windows masaüstünde o kadar baskındı ki, birçok yazılım yalnızca Windows üzerinde çalışacaktı. Microsoft araç zincirini takarsanız, Microsoft'un mülkünü kullanmak başka bir şey için endişelenmekten daha kolaydır ve birçok programcı da bunu yaptı.

Yukarıda tartışılan nedenlerin neredeyse hepsine katılıyorum, ancak buradaki birçok kişi, beraberinde getirdiği fazladan masraflar nedeniyle Qt kullanmayacaklarını söyledi. Buna katılmıyorum, çünkü bugün en yaygın dillerin tümü (Java, C # ve Python) oldukça fazla bir ek yük taşıyor.

İkincisi, Qt, C ++ ile programlamayı o kadar kolay ve yalındır, kullandığı ek kaynaklar için yapar. Yazma kolaylığı nedeniyle standart C ++ yerine Qt ile yazılmış birkaç konsol uygulamasına rastladım.

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

Bu gerçekten bir alev savaşı başlatma çabası değil, sadece bazı noktalara değinmek istedim.

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

Qt, bir C ++ kütüphanesi değildir. Yapı sürecini diğer kütüphanelerin çoğuyla karşılaştırıldığında daha karmaşık hale getiren ayrı bir derleme adımı gerektirir.

Visual Studio için vs-addin bunu otomatik olarak Qt'un kendi komut satırının yaptığı gibi yapar. MFC için diyaloglar oluşturmak için kullanılan kaynak derleyici de ayrı bir adım ama yine de c ++.

Qt, derlemeden önce kullandığınız herhangi bir makinede bulunması ve önceden yüklenmiş olması gereken büyük miktarda bir kaynaktır. Bu, inşaat ortamı oluşturmayı çok daha sıkıcı hale getirebilir.

Her görsel stüdyosunun sürümü için ikili bir indirme var ve kaynaktan derleme tek bir komut. SDK kaynak boyutunun bugünlerde çok fazla bir şey olduğunu görmüyorum. Visual studio şimdi seçip seçmenize izin vermek yerine tüm C ++ lib'lerini yükler, bunun sonucunda derleyicinin yükleme boyutu> 1 Gb'dir.

Yalnızca LGPL'de bulunur; bu, daha kısıtlayıcı veya daha az kısıtlayıcı bir lisans altında yayınlanması gerektiğinde tekli ikili dağıtımı kullanmayı zorlaştırır.

LGPL sadece lib için geçerlidir, kodunuzu etkilemez. Evet, tek bir ikili dosyadan ziyade DLL'leri göndermeniz gerektiği anlamına gelir (ödeme yapmazsanız), fakat küçük bir kullanım için Java çalışma zamanı veya. Ayrıca, tek bir ABI'ye sahip platformlarda da sorun yok, böylece diğer Qt uygulamaları lib'leri paylaşabilir.

Bazı durumlarda, yerel programların göründüğü gibi görünmüyor. Tüm platformlar için doğal olarak tek bir UI tasarlamak, çeşitli görsel şekillendirme nedenleriyle makineden makineye taşınırken doğru görünmeyecektir.

Yerel aletler ve temalar kullanması gerekiyordu. Çoğunlukla teknik uygulamalar yaptığımı itiraf etmeliyim ki kullanıcılarım stil konusunda fazla endişelenmiyorlar. Özellikle pencerelerde her şeyin bir akıllı telefon widget'ı olarak stil sahibi olmasının yeni modası, yine de bir standardın daha az olduğu anlamına geliyor.

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

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

Daha genel bir cevap olarak (ki burada ilgimi çekebildiğim için verebilirim), bazı programcılar bunu asla bırakmamış ve kullanmaya karar vermişlerdir. Bazı durumlarda, programcının hiçbir zaman buna ihtiyaç duymadığı ve araştırdığı dışında özel bir sebep yoktur.

Eğer ürün seyir için uğraşıyorsanız zaman Qt gibi Çerçeveleri uygun aynı ürününüz seyir ile daha tüm platformlarda doğru tüm platformlarda. Günümüzde giderek daha sık, bu tür uygulamalar web tabanlı teknolojilere geçiyor.

Qt'nin çalışmak için iyi bir çerçeve olduğuna katılıyorum. Yine de, onunla ilgili birkaç sorun var:

1. Gerçekten düşük seviyeli bir dil olan C ++ dilinde yazılmıştır. Tek başına C ++ olması, her Qt programcısını diğer dillerde yazılmış Altyapılara kıyasla çok daha az verimli hale getirecek. Bir GUI geliştirme dili olarak C ++ ile olan ana etim, otomatik bellek yönetimi kavramının yanında olmaması ve geliştirme sürecini hatalara daha yatkın hale getirmesidir. Hata ayıklamayı çok daha zor hale getiren iç içe geçmiş değildir. Diğer ana GUI araç setlerinin çoğunda, bazı otomatik bellek yönetimi ve iç gözlem kavramı vardır.
2. Her platformlar arası araç kiti, desteklenen platformların yalnızca en az ortak paydasını uygulayabilmesi probleminden muzdariptir. Bu ve farklı platformlardaki farklı UI yönergeleri, bir bütün olarak platformlar arası GUI'lerin arzu edilebilirliğini çok fazla sorgulamaktadır.
3. Qt, tüm kullanıcı arabiriminizi kodlamak üzerinde yoğunlaştı. Eğer rağmen edebilirsiniz senin UI bazı kısımlarını oluşturmak için QtDesigner kullanmak, ciddi karşılaştırması, diyelim ki, (Kakao / Obj-C) Arayüz Oluşturucu veya .Net araçları yoksundur.
4. Qt birçok düşük seviye uygulama işlevselliği içermesine rağmen, belirli bir platform için özel olarak tasarlanmış bir çerçeveye sahip olmasıyla karşılaştırılamaz. Hem Windows hem de OSX için yerel işletim sistemi kitaplıkları, Qt'nin uygulamalarından çok daha güçlü. (Ses çerçeveleri, düşük seviyeli dosya sistemi erişimi vb.

Bu, hızlı uygulama prototipleme veya şirket içi uygulamalar için PyQt'u kullanmayı seviyorum. Tüm kodlamaları yapmak için Python kullanmak, C ++ ile ilgili endişeleri hafifletir ve Qt'yi gerçekten çok hoş bir yer yapar.

Bazı yorumlara yanıt olarak düzenleyin:

Qt'nin C ++ 'da yazıldığından bahsettiğimde, Qt'un kendisinden çok şikayet etmiyordum, yaşadığı çevre hakkında daha fazla şikayet ediyordum. Qt'un kendi kaynaklarını çok iyi yönettiği, ancak GUI ile ilgili tüm ama Qt kodunun C ++ 'da da yazılması gerekir. Orada bile, Qt pek çok güzel araç sunuyor, ama sonuçta, C ++ ile o seviyede başa çıkmak zorundasın. Qt, C ++ 'ı katlanabilir kılar, ancak yine de C ++' dır.

İç içe girme gelince, demek istediğim şudur: Hata ayıklamak en zor durumlarda, olması gerektiği gibi davranmayan bir nesneye bir işaretçi varken. C ++ ile hata ayıklayıcınız bu nesnenin içine biraz bakabilir (bu, tür bilgisinin olması durumunda), ancak bu her zaman işe yaramaz bile. Öte yandan, aynı durumda Kakao alın. Cocoa / Obj-C'de, hata ayıklayıcısındaki bir nesneye mesajlar ('çağrı işlevleri') gönderebilirsiniz. Nesnelerin durumunu değiştirebilir, niteliklerini sorgulayabilir, türünü ve işlev adlarını isteyebilirsiniz ... Bu hata ayıklamayı çok daha kolaylaştırabilir. Qt / C ++ 'ın buna bile yakın bir şeyi yok.

Qt'yi gerçekten seviyorum, ancak birçok uygulama için biraz ağır. Bazen bu karmaşıklık seviyesine ihtiyaç duymazsın. Bazen sadece tüm Qt yükü olmadan basit bir şeye ihtiyacınız olur. Her uygulamanın olaya odaklı 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 seviye işlevsellik (dosya, soket, yönetilen işaretçiler vb.) İçerir.

Diğer uygulamaların GPL, LGPL veya Qt ticari lisansıyla iyi 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, birçoğunun ödemek istemediği bir şeydir.

Bazılarının Qt gibi karmaşık kütüphanelere izin vermeyen güvenlik veya istikrar konuları var.

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

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

İçinde platforma özgü bazı kazançlar var. Bu yakalananların çoğu belgelenmemiş. Yeterince büyük bir uygulama oluşturun ve bunlarla karşılaşacaksınız ve neler olup bittiğini merak edeceksiniz (feragatname, Qt'u öfkeyle en son kullandığımda 18 aydan fazla oldu, bu yüzden daha da iyileşmiş olabilir).

Sadece C ++. Diğer dil ciltleri var, ancak Qt için istediğiniz işlevselliğin birçoğunu gizlemeye ya da zayıf olarak göstermeye meyillidirler.

Qt kullanmamak için birçok neden var, bu yüzden alternatifler var. Sahip olduğun tek şey bir çekiçse, o zaman her sorun bir çiviye benzeyecek.

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

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

• Her özelleştirilmiş widget nesnesi olayını yeniden yazdınız, küçük değişiklikler yapıldı.
• Tüm Qt Designer ürünlerini kaybettiniz. Her widget'ı özel etkinliklerle tanıtmalısınız.
• Proje daha büyük ve sürdürülmesi zorlaştı.
• Bundan dolayı qt'yi beğenmedin. Net'in delegelere nasıl sağladığı, sinyal yuvasından çok daha iyi olduğu, .net bileşenlerinin (widget'lar) genellikle hayal edebileceğiniz her olayı nasıl sağladığı hakkında konuşmaya başlayın. Ve benzeri.

Üniversitemden biri, her bir açılan kutu widget'ı için yeni bir açılan kutu sınıfı yazdı, çünkü bazı işaret dışı olayları kullanmak zorunda kaldı. Gerçek hikaye...

Ancak, Qt, şimdiye kadar iniş ve çıkışlarla en iyi C ++ UI çerçevesidir.

kendi düşünceme göre, C ++ programlarını öğrenmek karmaşıklıklarını gizleyen diğer dillere düşmekten daha kolaydır ve programcı arka planda gerçekte ne olduğunu bilmiyor. Diğer taraftan, Qt, C ++ 'a doğal faydalar kazandırmak için C ++' a göre bazı avantajlar sağlar. Bu nedenle, Qt C ++, düşük seviyeli görevler veya aynı seviyede üst düzey görevler geliştirmek isteyenler için mükemmel bir çerçevedir. C ++ (bazı uygulamalara göre) karmaşık ve basit bir dildir. Onunla meydan okumayı istemeyen için karmaşık, onu sevenler için basit. Bunu karmaşıklığı için bırakma!

Asıl sebep teknik değil.

İnsanlar farklı oluyor. Seçimleri de öyle. Tekdüzelik bir insan özelliği değildir.