कंसूलो यूआई एपीआई विचार से प्रोटोटाइप तक

सभी को नमस्कार, लंबे समय तक मैंने हब पर परियोजना के जीवन के बारे में एक लेख नहीं लिखा था

कॉन्सुलो IntelliJ IDEA कम्युनिटी एडिशन का एक कांटा है जिसमें .NET (C #), जावा के लिए सपोर्ट है

चलिए शुरू करते हैं

प्रश्न: कॉन्सुलो यूआई एपीआई - यह क्या है?

A: यह UI बनाने के लिए API का एक सेट है। वास्तव में, विभिन्न घटकों को दोहराने वाले इंटरफेस का एक सरल सेट - बटन, रेडियोनबटन, लेबल, आदि।

प्रश्न: यूआई एपीआई का एक और सेट बनाने का उद्देश्य क्या है अगर पहले से ही स्विंग था (चूंकि आईडीए यूआई इंटरफ़ेस को प्रदर्शित करने के लिए स्विंग का उपयोग करता है)

ए: इसके लिए, आइए इस विचार में तल्लीन हो जाएं कि मैंने कौंसुल यूआई एपीआई पर काम करते समय इसका पालन किया था। चूंकि मैं कंसुलो परियोजना का मुख्य और लगभग एकमात्र योगदानकर्ता हूं, समय के साथ मेरे लिए उन परियोजनाओं की संख्या को बनाए रखना मुश्किल हो गया जो अब (लगभग 156 रिपोजिटरी) हैं। मास कोड विश्लेषण के बारे में एक सवाल था, लेकिन डेस्कटॉप प्लेटफॉर्म पर एक आईडीई उदाहरण के ढांचे के भीतर ऐसा करना असंभव है, और जेटब्रेन के अनुभव का उपयोग करने के लिए जहां एक विचार-अंतिम परियोजना में सभी प्लगइन्स हैं जो मैं कई कारणों से अभ्यास नहीं करना चाहता था।

वेब सर्वर पर विश्लेषण का विचार उत्पन्न हुआ। "सामान्य विश्लेषण" ने मुझे वेब सर्वर पर बहुत अधिक पसंद नहीं किया, मैं डेस्कटॉप पर भी एक ही तरह की वेब आईडीई (शुरुआत में कम से कम आसानी से) बनाना चाहता था।

आप कह सकते हैं कि यह थोड़ा अपस्कर्ट दोहराता है, विचार स्वयं समान है - लेकिन दृष्टिकोण पूरी तरह से अलग है।

और फिर वह क्षण आया - जब विचार था, लेकिन यह नहीं पता था कि यह कैसे करना है। मुझे GWT, वाडिन फ्रेमवर्क का उपयोग करने का अनुभव था - मैं जेएस (अच्छी तरह से, या सादे जेएस) पैदा करने के लिए अन्य गैर-जावा फ्रेमवर्क का उपयोग नहीं करना चाहता था।

मुझे इस पर शोध करने में एक महीना लगा। यह इस भाग में मेरी क्षमताओं का परीक्षण था। सबसे पहले मैंने केवल GWT का उपयोग किया - जानकारी के लिए मैंने अंतर्निहित RPC का उपयोग किया।

एक सरल लक्ष्य था - परियोजना पहले से ही खुली थी, केवल प्रोजेक्ट ट्री + संपादक टैब प्रदर्शित करना आवश्यक था। इस मामले में, सब कुछ डेस्कटॉप संस्करण के समान होना चाहिए।

तुरंत नए बने बैकएंड के साथ समस्याएं थीं। उदाहरण के लिए, आंतरिक क्रियाओं के लिए EventQueue का उपयोग करना

घटना के लिए संक्षेप में, यह एक यूआई (एडब्ल्यूटी, स्विंग) स्ट्रीम है। यूआई से संबंधित लगभग सब कुछ इसमें होता है - एक बटन क्लिक, प्रतिपादन, प्रसंस्करण।
ऐतिहासिक रूप से, IDEA में, लेखन कार्य हमेशा एक UI थ्रेड में किए जाने चाहिए।
लिखें कार्रवाई एक फ़ाइल के लिए एक रिकॉर्ड है, या कुछ सेवा में परिवर्तन होता है (उदाहरण के लिए, एक मॉड्यूल का नाम बदलना)

सबसे पहले, EventQueue के साथ समस्या को नजरअंदाज किया जा सकता है - लेकिन फिर अन्य समस्याएं दिखाई दीं। उदाहरण के लिए, बैकल आइकन । कल्पना कीजिए कि हमारे पास एक परियोजना का पेड़ है

• [] परियोजना का नाम
  
  • [] src
    
    • [] मुख्य.जावा
  • [] परीक्षण
  • [] build.gradle

और प्रत्येक फ़ाइल के लिए हमें एक तस्वीर अपलोड और प्रदर्शित करनी होगी। चूँकि हम स्विंग कोड के अंदर काम करते हैं, हम javax.swing.Icon वर्ग का उपयोग करते हैं। समस्या यह है कि यह सिर्फ एक इंटरफ़ेस है - जिसमें बहुत सारे अलग-अलग कार्यान्वयन हैं

• छवि आइकन एक आइकन है जो बस छवि को लपेटता है (यानी, फ़ाइल सिस्टम से एक नियमित छवि)
• लेयर्ड आइकन एक स्तरित आइकन है जिसमें दो या दो से अधिक आइकन होते हैं जो एक दूसरे के शीर्ष पर स्टैक्ड होते हैं
• अक्षम आइकन - ग्रे फ़िल्टर के साथ आइकन लागू किया गया
• पारदर्शी आइकन - निर्दिष्ट पारदर्शिता वाला आइकन
• और कई अन्य

नतीजतन, ब्राउज़र में आइकन दिखाने के लिए, आपको पूरे चिड़ियाघर (और लगभग सभी को एक बार) का समर्थन करने की आवश्यकता है। साथ में आने वाली समस्याओं में से एक यह है कि एक आइकन जो फ़ाइल के लिए आपके लिए पूरी तरह से अज्ञात है (उदाहरण के लिए, कुछ प्लगइन के अंदर पिक्सेल द्वारा एक प्रतीक पिक्सेल खींचा जाता है) - और इस तरह के नजरअंदाज करने की जरूरत है।

एक बैसाखी विधि के साथ (अच्छी तरह से, जहां उनके बिना) - एक निर्णय किया गया था। यह हमारे लिए आवश्यक प्रकार के लिए उदाहरण के माध्यम से जाँच करने के लिए ट्राइट है - और अन्य सभी को अनदेखा करें।

थोड़ी देर के बाद, फ़ाइल सिस्टम को नेविगेट करने, एक फ़ाइल खोलने, सिंटैक्स हाइलाइटिंग, सिमेंटिक विश्लेषण, त्वरित डॉक्टर जानकारी, कोड संदर्भों के लिए नेविगेशन (Ctrl + B जैसे एक संयोजन, या Ctrl + MouseClick1 का समर्थन किया गया) के लिए समर्थन किया गया था। संक्षेप में, संपादक डेस्कटॉप प्लेटफॉर्म के समान था।

यह कैसा लग रहा था:

तो - वेब इंटरफ़ेस बनाने के लिए मेरी ताकत के साथ संभव था। लेकिन यह बहुत कठिन काम था - जिसे फिर से करना पड़ा। और फिर वाडिन बचाव में आए।

मैंने वाडिन ढांचे का उपयोग करने के लिए अपने GWT कार्यान्वयन को फिर से करने का फैसला किया। यह परीक्षण बहुत खराब निकला (प्रदर्शन बहुत खराब हो गया था) - वाडिन का उपयोग करने के मेरे अनुभव ने इसे अधिक प्रभावित किया, और मैंने इस विकल्प को अस्वीकार कर दिया (मैंने इसके बारे में भूलने के लिए मौजूदा ब्रंच पर एक हार्ड-रीसेट भी किया: डी)।

लेकिन वाडिन का उपयोग करने का अनुभव मेरे लिए हर समय उपयोगी था, विचार उत्पन्न हुआ - यूआई को एकजुट करने के लिए ताकि आप एक कोड लिख सकें, लेकिन प्लेटफॉर्म के आधार पर आउटपुट पर अलग-अलग परिणाम प्राप्त कर सकें।

UI को एकीकृत करने का एक अन्य कारण IntelliJ प्लेटफॉर्म के अंदर स्विंग घटकों का पूरा चिड़ियाघर है। ऐसी समस्या का एक उदाहरण दो पूरी तरह से अलग टैब कार्यान्वयन है।

UI तर्क अलग करें:

• फ्रंटेंड - प्रत्येक तत्व के लिए इंटरफेस का एक सेट, उदाहरण के लिए consulo.ui.Button # create ()
• बैकेंड - प्लेटफ़ॉर्म आश्रित कार्यान्वयन
  
  • स्विंग - डेस्कटॉप कार्यान्वयन
  • WGWT - वेब कार्यान्वयन

WGWT क्या है? परिवर्णी शब्द के साथ GWT यह एक स्व-लिखित रूपरेखा है - जिसने घटक के स्टेट को संग्रहीत किया और इसे वेबसॉकेट के माध्यम से ब्राउज़र में भेजा (जो बदले में HTML उत्पन्न करता है)। उन्होंने वाडिन पर एक आँख से लिखा (हाँ हाँ - एक और बैसाखी)।

समय बीत गया - और पहले से ही मैं एक परीक्षण यूआई लॉन्च कर सकता था जो डेस्कटॉप और ब्राउज़र में समान काम करता था

मैंने समानांतर रूप से काम में वाडिन का उपयोग किया, क्योंकि यदि आप जावा का उपयोग करते हैं तो वेब UI बनाने के लिए यह सबसे सस्ता विकल्प है। मैंने वादिन का अधिक से अधिक अध्ययन किया - और मैंने फिर से WGWT को वाडिन को फिर से लिखने का फैसला किया, लेकिन कुछ सुधारों के साथ।

क्या संपादन थे:

• लगभग सभी वाडिन घटकों का उपयोग करने से इनकार। कई कारण थे - उनमें से एक भी सीमित घटक था (अनुकूलन न्यूनतम था)।
• मेरे WGWT ढांचे से मौजूदा घटकों का उपयोग करना; अर्थात् उनका GWT कार्यान्वयन
• एक पैच भी था जो आपको सर्वर घटक से सीधे लिंक के बिना कनेक्ट एनोटेशन लिखने की अनुमति देता था (यह क्लाइंट कोड के अंदर सर्वर वर्गों की उपलब्धता से बचने के लिए, प्रोजेक्ट संरचना के लिए अधिक किया गया था)

नतीजतन, यह इस तरह निकला:

• फ्रंटेंड - प्रत्येक तत्व के लिए इंटरफेस का एक सेट, उदाहरण के लिए consulo.ui.Button # create ()
• बैकएंड - प्लेटफॉर्म के आधार पर वर्तमान कार्यान्वयन
  
  • स्विंग - डेस्कटॉप कार्यान्वयन
  • वाडिन - वेब कार्यान्वयन
  • एंड्रॉयड? - एप्लिकेशन की शुरुआत में फोन को जलाने के लिए: डी अब तक, केवल इस विचार के स्तर पर कि एंड्रॉइड पर स्थानांतरित करने के लिए मौजूदा कोड का उपयोग करना संभव होगा (क्योंकि स्विंग के लिए कोई बंधन नहीं होगा)

और इसलिए वर्तमान कॉन्सुलो यूआई एपीआई का जन्म हुआ।

कोंसुल यूआई एपीआई का उपयोग कहां किया जाएगा?

• सभी प्लगइन्स में। संकलन के दौरान AWT / स्विंग को "अवरुद्ध" (कोई और java.awt.Color ) नहीं किया जाएगा (एक जावा प्रोसेसर बनाया जाएगा - बाद में, यह जावा 9 के आगमन के साथ बिल्कुल भी आवश्यक नहीं हो सकता है)। आपके घटकों का सेट रामबाण नहीं है, मैं समझता हूं कि। फिलहाल, आप अपना स्वयं का कस्टम UI घटक बना सकते हैं, अब तक केवल स्विंग साइड पर (और ऐसे मामलों में वेब सर्वर पर समस्याओं से बचने के लिए consulo.destop प्लगइन पर निर्भरता जोड़ना आवश्यक होगा)। प्लगइन पक्ष पर वाडिन घटकों का निर्माण अभी तक नहीं हुआ है - होगा, यह एक मामूली काम है।
• प्लेटफ़ॉर्म की तरफ, ये सेटिंग्स / प्राथमिकताएं, रन कॉन्फ़िगरेशन, संपादक - अनिवार्य रूप से संपूर्ण इंटरफ़ेस है जो जेफ्रेम पर जाता है।

क्या समस्याएं हैं?

• AWT / स्विंग कोड के साथ पूरी तरह से असंगत है (एक बैसाखी वर्ग TargetAWT / TargetVaadin है जिसमें घटकों को परिवर्तित करने के तरीके हैं, लेकिन ये वर्ग प्लगइन्स के लिए सुलभ नहीं हैं)।
  सभी स्विंग घटकों को ब्राउज़र में प्रदर्शित नहीं किया जा सकता है - परिणामस्वरूप, आपको इस सभी कोड को फिर से लिखना होगा।
  लगभग हर जगह, कॉन्सुलो यूआई एपीआई पहले से ही प्लेटफॉर्म के अंदर समर्थित है - यह आपको प्लगइन्स के अंदर और न केवल नए यूआई ढांचे का उपयोग करने की अनुमति देता है।
• IntelliJ प्लेटफ़ॉर्म का स्विंग के प्रति बहुत गहरा लगाव, इसे इतनी गहराई से दफनाया जाता है कि "अगले" बैसाखी के बिना, आप इसे खोद नहीं सकते ( )।

कुछ समय बाद

यह कोड दोनों प्लेटफार्मों पर समान काम करता है।

डेस्कटॉप पर उनका काम:

ब्राउज़र में उनका काम:

उपरोक्त समस्याओं के बारे में:

• प्रतीक। वर्ग consulo.ui.image.Image पेश किया गया था, जो फ़ाइल सिस्टम से एक तस्वीर है (और न केवल)। चित्र अपलोड करने के लिए आप consulo.ui.image.Image # create (java.net.URL) विधि का उपयोग कर सकते हैं।

डेस्कटॉप प्लेटफ़ॉर्म पर - आइकन लोड किए गए हैं क्योंकि वे पहले लोड किए गए थे, अब केवल रिटर्न प्रकार SwingImageRef (विरासत वर्ग का नाम - पूर्व में consulo.ui.image.Image है, जिसे consulo.ui.ImageRef कहा जाता है - एक इंटरफ़ेस जो javax.swing.Icon और consulo.ui को विरासत में मिला है। .image.Image। बाद में इस इंटरफ़ेस को हटा दिया जाएगा (इसका अस्तित्व एक नए प्रकार के सरलीकृत प्रवास के कारण है)

वेब प्लेटफ़ॉर्म पर - URL ऑब्जेक्ट के अंदर संग्रहीत किया जाता है, और इंटरफ़ेस में प्रदर्शन के लिए पहचानकर्ता है (URL के माध्यम से - / app / uiImage = URLhashCode )

ImageEffects वर्ग पेश किया गया है। यह व्युत्पन्न चिह्न बनाने के लिए आवश्यक विधियों के भीतर है। उदाहरण के लिए, #grayed (छवि) एक ग्रे फ़िल्टर के साथ एक आइकन लौटाएगा, #transparent (छवि) एक पारभासी आइकन।

यही है, ऊपर वर्णित पूरे पूरे चिड़ियाघर को संकीर्ण फ्रेम में संचालित किया गया था।

तत्वों के मैनुअल प्रतिपादन के लिए समर्थन (अच्छी तरह से, जहां बिना इसके) भी पेश किया जाएगा। विधि ImageEffects # कैनवास (इंट ऊंचाई, इंट चौड़ाई, कंज्यूमर <Canvas2D> चित्रकारकंसमर) Canvas2D के माध्यम से खींचा गया एक आइकन लौटाएगा

डेस्कटॉप पर - रैपर को नियमित ग्राफिक्स 2 डी के शीर्ष पर स्विंग से इस्तेमाल किया जाएगा

वेब पर - कैनवस 2 डी के तरीकों के लिए हर कॉल को सहेजा जाएगा, और फिर इसे उस ब्राउज़र में स्थानांतरित किया जाएगा जहां ब्राउज़र से आंतरिक कैनवस का उपयोग किया जाएगा

• UI थ्रेड में क्रिया लिखें। Oooo। इस समस्या का अभी तक कोई समाधान नहीं हुआ है। फिलहाल - स्वयं थ्रेड में एक प्रोटोटाइप लिखें एक्शन है लेकिन अभी तक केवल वेब प्लेटफॉर्म पर, डेस्कटॉप पर "इसे रोल आउट" करने के लिए प्लेटफॉर्म के अंदर बहुत अधिक परिवर्तन करने की आवश्यकता है।
• यूआई को एकीकृत किया गया है - सरल तत्वों के लिए कोई चिड़ियाघर नहीं

एक नई समस्या भी सामने आई - स्विंग डायलॉग शो के दौरान निष्पादन थ्रेड को ब्लॉक करते हैं। परिणामस्वरूप, IDEA इस रूप में कोड लिखना पसंद करता है:

DialogWrapper wrapper = ...; int value = wrapper.showAndGet(); if(value == DialogWrapper.OK) { ... } 

उसी समय, वाडिन में संवाद प्रदर्शित करने से निष्पादन थ्रेड ब्लॉक नहीं होता है।

संवादों के सिंक्रोनस और एसिंक्रोनस डिस्प्ले के साथ भ्रम से बचने के लिए, एक एसिंक्रोनस विकल्प चुना गया था (उपरोक्त कोड को फिर से जोड़ा और फिर से बनाना होगा)।

परिणाम

थोड़ी देर के बाद, मेरे पास वेब एप्लिकेशन का एक कार्यशील प्रोटोटाइप है।

अब तक यह एक प्रोटोटाइप है जो अपनी रिलीज़ की ओर बढ़ रहा है - लेकिन यह तेज़ (अफसोस) नहीं होगा।