Eto: [Req] नेटिव (शुद्ध C#) वेलैंड बैकएंड सपोर्ट

सलाह के लिये धन्यवाद! हालाँकि, जब हम पहले से ही GTK (जो कि वेलैंड के ऊपर बैठते हैं) का उपयोग करते हैं, तो हम सीधे वायलैंड से क्यों जुड़ेंगे? क्या यह पहिया को सुदृढ़ नहीं करता है? जो मैं समझता हूं, हमें सभी विजेट्स, विंडोिंग कार्यक्षमता इत्यादि को लागू करना होगा।

आप इस दृष्टिकोण के लाभ के रूप में क्या देखते हैं?

यह अच्छा विचार है, लेकिन मोनो फ्रेमवर्क या .net कोर के लिए ईटो फ्रेमवर्क के लिए नहीं। फायदे स्पष्ट हैं। Eto -> gtk# -> mono/.net core -> gtk+ -> xwindow. केवल eto -> mono/.net core -> वेलैंड।

मैं गलत हो सकता था, लेकिन ऐसा प्रतीत होता है कि वेलैंड सिर्फ एक कंपोजिटर प्रदान करता है। ऐसा लगता है कि यह रेखाएं, ग्रेडियेंट, बनावट इत्यादि खींचने के लिए एक ड्राइंग एपीआई प्रदान नहीं करता है। यह कैरो जैसा कुछ प्रदान करेगा और इसे बहुत अच्छी तरह से करता है। मैं ईटो की कल्पना नहीं करता हूं। अपने स्वयं के ड्राइंग एपीआई को लागू करने वाले फॉर्म जो एक बफर को प्रस्तुत करते हैं, क्योंकि यह पहिया का फिर से आविष्कार करेगा और शायद इसे खराब तरीके से करेगा।

हालांकि, मैंने अक्सर Eto.Drawing api का उपयोग करते हुए प्रत्येक Eto के नियंत्रण (जैसे कि बटन, टेक्स्टबॉक्स, आदि) के लिए कस्टम तैयार हैंडलर बनाने पर विचार किया है। इसका मतलब यह होगा कि किसी को इसका समर्थन करने के लिए प्लेटफॉर्म के लिए केवल Eto.Drawing हैंडलर को लपेटना होगा (यदि आप इसकी परवाह नहीं करते हैं कि यह कैसा दिखता है)।

Eto.Forms पहले से ही काहिरा (जो वेलैंड का समर्थन करता है) को लपेटता है, इसलिए यह केवल प्रत्येक नियंत्रण के लिए कस्टम-ड्रॉ हैंडलर बनाने की बात होगी और हम कम से कम GTK+ को काट सकते हैं। हालाँकि, यह अभी भी बहुत काम है। अगर कोई काफी उत्सुक है, तो यह एक स्वागत योग्य अतिरिक्त होगा और मैं इसे शुरू करने में मदद कर सकता हूं, लेकिन ज्यादा काम नहीं कर पाऊंगा।

क्या इस विचार में अभी भी कोई दिलचस्पी रखता है? मैं वेलैंड के लिए एक बाध्यकारी बनाने में कामयाब रहा हूं जो सी # को आसानी से यूजर इंटरफेस बनाने के लिए वेलैंड का उपयोग करने में सक्षम बनाता है। मैं इसके लिए रेपो अपलोड करने से पहले डिजाइन को अंतिम रूप देने की योजना बना रहा हूं। (यह अनिवार्य रूप से देशी वेलैंड लाइब्रेरी को गतिशील रूप से लोड करने के लिए डीएल लाइब्रेरी का उपयोग कर रहा है जो वही लाइब्रेरी है जिसे मोनो डीएलएल फ़ंक्शंस और इंटरफ़ेस को सीधे आयात करने के लिए उपयोग करता है। इंटरमीडिएट लाइब्रेरी को वेलैंड और सी # के बीच पी/इनवोक को संभालने की आवश्यकता नहीं है।) मैं भी हूं काहिरा के बजाय ImageSharp का उपयोग करना (काहिरा स्पष्ट रूप से साझा मेमोरी बफर के साथ बातचीत नहीं कर सकता है सीधे मेरे प्रयासों से घृणा करता है।)

मैं वास्तव में यह नहीं देखता कि यह मुद्दा एक चीज भी क्यों है... आप क्या हासिल करेंगे?

GTKSharp और GTK निर्भरता की जरूरतों को खत्म करना एक बड़ी बात है। वेलैंड अपेक्षाकृत तेज और लचीला है कि हम स्की, ओपनजीएल, इमेजशर्प, या अन्य पुस्तकालयों का उपयोग कर सकते हैं ताकि हमारे ईटो को प्रस्तुत करने के लिए पुस्तकालयों को सूचीबद्ध किया जा सके। उपयोगकर्ता इंटरफ़ेस जो उपयोगकर्ताओं को विशेष रूप से एम्बेडेड वातावरण में अधिक विकल्प प्रदान करता है (https://www.youtube.com/watch?v=GtXQJ0c5q0k यह देखने के लिए कि एआरएम डिवाइस पर वेलैंड का उपयोग कैसे किया जाता है)।

दुनिया में आप gtk/qt पर रिले किए बिना जस्ट वेलैंड के साथ एक बटन कैसे प्रस्तुत करेंगे और फिर भी इसे मूल दिखेंगे?

आप इसे या तो छवियों द्वारा सीमाओं या कोड द्वारा प्रस्तुत करने के लिए आकर्षित करते हैं। यह आपके विचार से आसान है और HTML वेब डिजाइनिंग के समान है। ImageSharp उस कार्य को आसान बनाने के लिए C# के लिए जिम्प के समान कई सुविधाएँ प्रदान करता है ताकि एक चीज़ जो हम पहले से ही कर रहे हैं।

आप इसे या तो छवियों द्वारा सीमाओं या कोड द्वारा प्रस्तुत करने के लिए आकर्षित करते हैं। यह आपके विचार से आसान है और HTML वेब डिजाइनिंग के समान है।

ईटो फॉर्म का उद्देश्य मंच के लिए मूल यूजर इंटरफेस प्रदान करना है, जो यह मुद्दा पूछ रहा है वह एक परियोजना के लिए अधिक उपयुक्त होगा जैसे: https://github.com/AvaloniaUI/Avalonia

और मेरी बात अभी भी कायम है, हम मूल यूजर इंटरफेस प्रदान करने के लिए ईटो के तहत एक सी # प्लेटफॉर्म बना सकते हैं जो सिर्फ लिनक्स ही नहीं, बल्कि सभी प्लेटफॉर्म पर काम कर सकता है।

और मेरी बात अभी भी कायम है, हम मूल यूजर इंटरफेस प्रदान करने के लिए ईटो के तहत एक सी # प्लेटफॉर्म बना सकते हैं जो सिर्फ लिनक्स ही नहीं, बल्कि सभी प्लेटफॉर्म पर काम कर सकता है।

आप कस्टम ड्राइंग होंगे, UI मूल नहीं लगेगा।

मुझे लगता है कि इस माहौल में, कोई अन्य UI टूलकिट नहीं होगा, इसलिए 'मूल' जैसी कोई चीज़ नहीं होगी। मैंने अक्सर थीम वाले हैंडलर बनाने के बारे में सोचा है जो सभी ड्रायबल नियंत्रणों तक उबालते हैं, जिसके लिए केवल एक ड्राइंग स्टैक को लागू करने की आवश्यकता होगी। हालाँकि, @cra0zy सही है कि

तो आप कह रहे हैं कि ईटो प्रोजेक्ट विकल्पों के लिए खुला नहीं होगा और जीटीके जैसे फूला हुआ पुस्तकालयों के साथ ही रहेगा, इससे दूर जाना संभव है?

@CsharpOnLinuxDev नहीं, मैं इसके लिए तैयार हूं। ईटो को प्रतिबंधित करने का कोई मतलब नहीं है, और यदि आप (या कोई भी) सोचते हैं कि वैकल्पिक प्लेटफॉर्म को आधार बनाने के लिए यह एक अच्छा ढांचा होगा, तो मैं इसका पूरा समर्थन करता हूं। मुझे लगता है कि एम्बेडेड प्लेटफॉर्म के लिए जीटीके या क्यूटी जैसे मौजूदा यूआई टूलकिट के बिना प्लेटफॉर्म का समर्थन करने के लिए निश्चित रूप से उपयोग का मामला है। इसका उपयोग .NET कोर के साथ विंडोज़ का समर्थन करने के लिए भी किया जा सकता है, ऐसा लगता है कि बहुत से लोग इसके लिए थोड़ा-थोड़ा कर रहे हैं।

कहा जा रहा है, मेरे पास इस तरह के मंच को विकसित करने या बनाए रखने के लिए कोई चक्र नहीं है, इसलिए इस पर कोई प्रगति समुदाय से आनी होगी। यह भी जरूरी नहीं कि मुख्य ईटो रेपो का हिस्सा हो, कोई भी ईटो के लिए एक मंच कार्यान्वयन बना सकता है और इसे अपनी पसंद के अनुसार प्रकाशित कर सकता है। (;

मैं (हमेशा की तरह) मदद और मार्गदर्शन प्रदान कर सकता हूं, जो कोई भी पूछता है।

नमस्ते, क्या इस पर कोई प्रगति हुई है? क्या वेलैंड को ईटो में एकीकृत किया जाएगा?

ठीक है अगर आप जीटीके 3 बैकएंड का उपयोग कर रहे हैं तो आप पहले से ही वेलैंड का उपयोग कर रहे हैं ...

@cra0zy आपके उत्तर के लिए धन्यवाद!
लेकिन मेरा मतलब है eto -> mono/.net core -> wayland , न कि Eto -> gtk# -> mono/.net core -> gtk3 -> wayland ।

असल में मैं एक वेलैंड सी # वारपर खोजने की कोशिश कर रहा हूं। मैं