बहुत से लोगों के बारे में एक राय है जो बेहतर है। मैं वास्तव में इन विचारों के लिए नहीं पूछ रहा हूं, जो मैं जानना चाहता हूं वे विवरण हैं: ऐसी चीजें क्या हैं जो एक ग्राफिकल टूलकिट को दूसरे से अलग बनाती हैं, और इनमें से कौन सा अंतर क्यूटी और जीटीके + करता है?जीटीके + और क्यूटी के बीच अंतर क्या हैं?
मैं सीधे जीटीके + से बात नहीं कर सकता, लेकिन मेरे पिछले काम पर मैंने जीटीकेएम का इस्तेमाल किया, और मेरे वर्तमान काम पर मैं क्यूटी का उपयोग करता हूं। दोनों सी ++ हैं, इसलिए उस संबंध में वे लगातार हैं, लेकिन जीटीकेएम जीटीके + कोड के लिए केवल एक रैपर है, जो सीधे सी
जब मैंने नौकरियों को स्विच किया, तो मुझे याद आया कि मुख्य मतभेदों में से एक यूआई कोड में दो टूलकिट लेआउट को कैसे संभाला गया था। कुछ हिस्सों में मैंने सोचा कि जीटीके ने बेहतर किया है, कुछ मैंने सोचा कि क्यूटी बेहतर था। दोनों आपको अपने विजेट्स प्राप्त करने देते हैं, जहां आप उन्हें चाहते हैं।
जीटीकेएमएम के साथ डीबगिंग दर्द का एक सा था, क्योंकि कक्षाएं आमतौर पर एक संरचना को पॉइंटर रखने और जीटीके + कार्यों को कॉल करने के अलावा कुछ भी नहीं करती थीं। संकेत का वह अतिरिक्त स्तर परेशान हो सकता है।
क्यूटी में अधिक सहायक कोड है जो कम से कम Gtkmm के संस्करण की तुलना में विभिन्न सेटिंग्स में उपयोगी हो सकता है। थ्रेडिंग, इंटर-प्रोसेस संचार, और नेटवर्किंग को आसान बनाने की चीजें सभी की सराहना की जाती है जब आपको अपने प्रोग्राम में नया आयाम जोड़ने की आवश्यकता होती है। उनके कंटेनर भी होते हैं, यदि आप उन लोगों का उपयोग करना चाहते हैं, जो मुझे लगता है कि एसटीएल कंटेनर की तुलना में एक सैंटर इंटरफेस है - लेकिन वे अंत में एक ही चीज़ के बारे में करते हैं, तो यह थोड़ा सा फायदा है।
जीटीकेएमएम और क्यूटी के बीच सिग्नल/स्लॉट तंत्र अलग है। क्यूटी मेटा सूचना उत्पन्न करने के लिए संकलन प्रक्रिया में एक अतिरिक्त चरण पर निर्भर करता है, जो इसके सिग्नल/स्लॉट के लिए उपयोग करता है। सिग्नल या स्लॉट का उपयोग करने वाली एक वस्तु को क्यूओब्जेक्ट से प्राप्त होना चाहिए, और क्यूओब्जेक्ट विरासत पहले ही नहीं होना चाहिए, जिसमें कोई हीरा संरचना नहीं है। यह एक सार तत्व को परिभाषित करना एक अमूर्त इंटरफ़ेस को परिभाषित करना मुश्किल बनाता है, उदाहरण के लिए। प्लस तरफ, वे थ्रेडिंग मुद्दों के स्वाभाविक रूप से अवगत हैं, और सिग्नल/स्लॉट कनेक्शन को आवश्यक होने पर ईवेंट-आधारित कनेक्शन में परिवर्तित कर देंगे। जीटीकेएमएम सिग्सी सिग्नल का उपयोग करता है, जो सी ++ कक्षाएं सीधी हैं, और मेरे लिए व्यापक परिस्थितियों में उपयोगी प्रतीत होता है। साथ ही, केवल उन ऑब्जेक्ट्स जो कनेक्शन को बनाते हैं, उन्हें जादू बेस क्लास से प्राप्त करने की आवश्यकता होती है, जैसा कि मुझे याद है। इसके अलावा, चूंकि स्लॉट ऑब्जेक्ट्स हैं, इसलिए आप उन्हें बहुत अच्छी अनुकूलनीय मज़ेदार ऑब्जेक्ट्स के रूप में भी उपयोग कर सकते हैं।
मुझे यकीन है कि अन्य अंतर भी हैं, लेकिन अब मुझे याद है। ध्यान रखें कि जीटीकेएमएम के साथ मेरा आखिरी अनुभव लगभग 3 साल पहले था, इसलिए उनमें से कुछ आइटम अब तक बदल सकते हैं।
सबसे पहले और सबसे महत्वपूर्ण, आप सीटी क्यूटी से जीटीके + का उपयोग कर सकते हैं केवल सी ++ है।
इसके अलावा, जीटीके + अनुप्रयोगों में संवाद बंद होते हैं जो एक करीबी बटन के साथ लगातार बदलते हैं। क्यूटी ओके/लागू/रद्द करने की लाइनों के साथ रहती है। मुझे नहीं पता कि यह टूलकिट स्तर पर कितना लागू होता है, हालांकि।
प्रोग्रामिंग के लिए, मुझे नहीं पता कि कॉलबैक तंत्र जीटीके क्या उपयोग करता है, लेकिन क्यूटी के संकेत-स्लॉट तंत्र पूरी तरह से चट्टानों का उपयोग करते हैं।
मतभेदों को समझने के लिए, इतिहास को समझना सर्वोत्तम है।
क्यूटी को यूआई के रूप में विकसित किया गया था और शुरुआत में कुछ लाइसेंसिंग मुद्दे थे जब केडीई पहले विकसित होना शुरू हुआ था। केडीई ने क्यूटी चुना क्योंकि वहां बहुत अधिक चयन नहीं था (मोटीफ, टीसीएल/टी कुछ नाम देने के लिए)
जीआईएमपी विकसित होना शुरू हो गया था और उस समय विंडो टूलकिट खरोंच तक नहीं थे डेवलपर्स की जरूरत है ताकि वे गिंप टूल किट (जीटीके) लिखना शुरू कर सकें। कुछ समय बाद जीटीके को फिर से लिखने और ऑब्जेक्ट ओरिएंटेड (जीटीके +) बनाने का फैसला किया गया।
इस समय, क्यूटी के साथ संभावित लाइसेंसिंग मुद्दों के कारण, जीनोम शुरू किया गया था और जीटीके + लाइब्रेरी का उपयोग करने का फैसला किया गया था।
अब यदि आप विकिपीडिया पर QT Design और GTK Design प्रविष्टियां देखते हैं, तो आप सिस्टम के बीच कुछ अंतर देखना शुरू कर सकते हैं।
सूचना है कि क्यूटी एक के रूप में भेजा जाता है:
पार मंच अनुप्रयोग विकास ढांचे
जीटीके + एक के रूप में भेजा जाता है, जबकि:
पार मंच विजेट Toolkit ग्राफिकल यूजर इंटरफेस बनाने के लिए।
यदि इन प्रविष्टियों पर विश्वास किया जाना है तो मुझे लगता है कि हम दोनों के बीच प्रमुख अंतर हो सकते हैं, लेकिन मैं आज की दुनिया में यह एक अच्छी लाइन कहूंगा।
यह वास्तव में एक अंतर नहीं है। इसका मतलब केवल जीटीके अलग पुस्तकालयों (ग्लिब, गोब्जेक्ट इत्यादि) के साथ मूलभूत चीजें करता है, जबकि क्यूटी के पास क्यूटीकोर में सबकुछ है। एक करीबी तुलना QtGui बनाम जीटीके होगा। –
क्रॉस प्लेटफार्म क्षमताओं को देखते समय एक और ऐतिहासिक मुद्दा यह है कि इसे क्यूटी की पहली स्रोत रेखा से लिया गया था, जहां जीटीके को शुरुआत से एक्स 11 टूलकिट के रूप में डिजाइन किया गया था और फिर इसे कुछ ऐसा करने के लिए बढ़ा दिया गया है बाद में पार मंच। अलग-अलग चीजों के लिए कई libs होने से वास्तव में क्रॉस प्लेटफार्म एक चमकदार हो सकता है, क्यों क्यूटी मेरी पसंदीदा पसंद है। – e8johan
मैंने पहले सुना है (वह क्यूटी केवल सी ++ है), लेकिन मुझे वास्तव में समझ में नहीं आता है कि इसका क्या अर्थ है। मैं सी #, पायथन, आदि में जीटीके + का उपयोग कर सकता हूं। मुझे पता है कि आप कम से कम पायथन में क्यूटी का उपयोग कर सकते हैं। इसका क्या अर्थ है कि क्यूटी केवल सी ++ है? –
@ मैथ्यू: इसका मतलब यह है कि आप इसे सी के साथ उपयोग नहीं कर सकते हैं। हालांकि, आप किसी उच्च-स्तरीय भाषा (पायथन, रूबी, जो भी हो) पर बाइंडिंग कर सकते हैं। –
बनाम "स्वचालित सेटिंग्स की बचत" बनाम "ठीक है, लागू करें, रद्द करें" वास्तव में एक जीनोम बनाम केडीई चीज है। दोनों टूलकिट या तो संभाल सकते हैं। –