प्रेत ओएस: विंडो सबसिस्टम - नियंत्रण करते हैं

आज हम बात करेंगे कि ग्राफिक फन यूआई को कैसे व्यवस्थित किया जाता है।

(फैंटम ओएस क्या है आप इन लेखों को पढ़कर पता लगा सकते हैं।)

अधिक सटीक रूप से - यह ग्राफिक UI कैसे पैदा हुआ था। लंबे समय तक फैंटम का केवल एक ग्राफिक निष्कर्ष था - माउस के साथ सिस्टम को कुछ भी बताना लगभग असंभव था।

अब समय आ गया है कम से कम सरल - लेकिन अनुप्रयोग, जिसका अर्थ है - आपको यूआई की आवश्यकता है। वैसे भी - प्रणाली, हम ईमानदार होंगे, यह डरावना लग रहा था। और यह अब फैशन में नहीं है।

UI परियोजना के प्रारंभ में क्या उपलब्ध था? सिद्धांत रूप में - बहुत कुछ।

वास्तव में, ग्राफिक्स था - एक वीडियो ड्राइवर, डिस्प्ले-ओनली मोड में एक विंडो सबसिस्टम, बिटमैप फोंट, एक विंडो इवेंट सबसिस्टम (ईवेंट), विंडो फ़ोकस कंट्रोल और संबंधित प्राइमिटिव।

अब कदम और थोड़ा और।

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

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

कार्यों की अगली परत विंडो सबसिस्टम है। यहां एक विंडो, विंडो डेकोरेशन (फ्रेम, बटन के साथ टाइटल विंडो), विंडोज़ के x / y / z निर्देशांक और फ़ंक्शंस का एक सेट है, जो स्क्रीन पर विंडो ड्रॉ करने और सभी एक्सिस पर उनके मूवमेंट को नियंत्रित करने के लिए ज़िम्मेदार हैं।


निम्नलिखित घटनाएं अनुसरण करती हैं - माइक्रोटस्क क्यू, जो निम्न-स्तर के ड्राइवर द्वारा खिड़कियों की स्थिति को प्रस्तुत करने और प्रबंधित करने के लिए संसाधित किया जाता है।

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

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

यह बस माउस (दबाया, खींचा), कीबोर्ड (दबाया, जारी किया गया) और विंडो सिस्टम से ही घटनाओं की धारा को प्राप्त करता है (माध्यमिक घटनाओं - खिड़की ऊपर जाने के बाद, स्क्रीन क्षेत्र को फिर से व्यवस्थित करें)।

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


अगला स्तर खिड़की पर ड्राइंग के लिए ग्राफिक आदिम है।

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

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

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

प्रोजेक्ट "न्यू फैंटम यूआई" की शुरुआत में ग्राफिक्स सबसिस्टम की समृद्धि और समाप्त हो गई। सिद्धांत रूप में, इस सज्जन की किट बहुत कुछ के लिए पर्याप्त थी, लेकिन केवल उपयोगकर्ता की ओर। कोई इनपुट नहीं।

अधिक सटीक रूप से, "बटन" की अवधारणा के लिए एक अल्पविकसित समर्थन था, लेकिन केवल माउस के साथ, केवल टूलबार में और केवल खिड़की बंद करने के लिए। :)

विकास कार्य निम्नानुसार था:

• ट्रू टाइप। इसके बिना, यह शर्म की बात है।
• कीबोर्ड इवेंट और कीबोर्ड कंट्रोल। कम से कम बुनियादी।
• लेआउट के स्थानीयकरण के बारे में सोचने के लिए - कम से कम सिरिलिक वर्णमाला, लेकिन लेआउट बदलने के लिए नींव रखना।
• नियंत्रण - बटन, रेडियो बटन, पाठ क्षेत्र, लेबल, मेनू और इतने पर।
• नियंत्रण का ध्यान खिड़की के अंदर नियंत्रण बिंदु का चुनाव है।
• स्क्रीन पर खिड़कियों के प्रबंधन के लिए स्क्रीन घटक के कुछ प्रकार। टास्क बार?
• दरअसल, नियंत्रण की छवियां और सामान्य रूप से कुछ यूआई डिज़ाइन - सामूहिक खेत के रूप में नहीं होना चाहिए जैसा कि यह था।

यह इस तरह था:



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

इस वजन के दृष्टिकोण को तीन बड़े भागों में विभाजित किया गया है: डिज़ाइन, ट्रम्प, बाकी।

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

ट्रम्प प्रकार

मैं इस से डर गया था, लेकिन, जैसा कि यह निकला, व्यर्थ में। वहाँ है libfreetype, अनुप्रयोग उदाहरण हैं, दो दिनों के बाद वेक्टर फोंट के प्रतिपादन ने परीक्षण मोड में काफी अच्छा काम किया।

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

दूसरा सरल है - मुफ्त फोंट की माला प्रचुर मात्रा में है, और उनका संगठन लंबा नहीं होगा।

लेकिन पहले ...

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

यह उतना मुश्किल नहीं है, लेकिन, जाहिरा तौर पर, अगले चरण का कार्य है। जबकि फोंट अपील के आधार पर व्यवस्थित होते हैं।

यूनिकोड

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

कीबोर्ड के साथ काम करें

सैन्य कार्रवाई का कोई संकेत नहीं था, लेकिन, आशाओं से अधिक, मुझे लड़ना पड़ा। यह पता चला कि पुराने कीबोर्ड ड्राइवर अभी भी है ... आईबीएम पीसी एक्सटी से हार्डवेयर देखने की उम्मीद है। हां, पिछली सदी। तथ्य यह है कि कीबोर्ड नियंत्रक आधुनिक कीबोर्ड (स्कैन कोड के तथाकथित दूसरे सेट) को उस प्राचीन एक में परिवर्तित करने में सक्षम (!) है।

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

इसके अलावा, स्थानीयकरण ऐसे मॉडल पर पूरी तरह से गिर गया। वांछित भाषा (वर्ण सेट), और चीयर्स के लिए ASCII-> UTF32 तालिका को ओवरले करने के लिए पर्याप्त है - हमारे पास सिरिलिक है। अच्छा - लगभग वहाँ। अब इसे या तो UTF-8 में ट्रांसकोड करना आवश्यक होगा, या UI के कुछ भागों को UTF-32 में रीमेक करना होगा। मैंने भी, इस क्षण को कम प्राथमिकता के रूप में रखा है।

नियंत्रण

बटन, रेडियो, चेकबॉक्स और अन्य विशिष्ट यूआई तत्व।

आम बुनियादी ढांचे में शामिल हैं:

• खिड़की के संबंध में नियंत्रण के भंडारण के लिए तंत्र
• विशिष्ट नियंत्रण दृश्य तत्व - फ़्रेम, पृष्ठभूमि, पाठ, आइकन, आदि।
• घटना नियंत्रण और विशिष्ट प्रतिक्रिया पैटर्न में संचरण (पुश / टॉगल)
• ट्रैकिंग माउस घटनाओं और मंडराना राज्य
• राज्य परिवर्तनों के बारे में सूचित करने के लिए कॉलबैक और माध्यमिक घटनाओं की पीढ़ी

नियंत्रण पर ध्यान दें

नियंत्रण के लिए (बटन, उदाहरण के लिए) माउस के बिना उपयोग करने के लिए, कई चीजों की आवश्यकता होती है।

• कीबोर्ड से इसका चयन करने की क्षमता
• इस चयन को प्रदर्शित करें
• कीबोर्ड की प्रतिक्रिया
• फोकस हानि का पता लगाना।

सबसे कठिन है।

वास्तव में, नियंत्रण कीबोर्ड और माउस दोनों के साथ केंद्रित है, और यह एक और एक ही इकाई है - यदि हम माउस के साथ एक पाठ क्षेत्र का चयन करते हैं, तो यह कुंजियों का भी जवाब देगा। यदि उसके बाद आप TAB दबाते हैं, तो कीबोर्ड के साथ काम करने का अधिकार दूसरे को जाएगा।

एक अलग कार्य यह है कि कुछ नियंत्रणों को समूहीकृत किया जा सकता है और उनकी स्थिति को संबंधित तरीके से अद्यतन करने की आवश्यकता होती है। एक रेडियोबैथॉर्न को दबाकर अपने समूह के पड़ोसियों को "निचोड़" दिया जाता है।

एक बार फिर, इस तथ्य पर वापस जाएं कि हम लगातार ओएस लिख रहे हैं। इसका मतलब है कि संभावित नियंत्रण को लगातार रैम में संग्रहीत किया जा सकता है और सिस्टम कर्नेल के रिबूट से बच सकता है।

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

अंत में, टास्क बार। यह स्क्रीन के नीचे (साइड, टॉप) पर एक ऐसी चीज है, जहां उपयोगकर्ता अगर खिड़की खो देता है, तो वह चुटकी लेता है।

सिद्धांत रूप में, यह पहले से ही उपयोगकर्ता भूमि का हिस्सा होना चाहिए, लेकिन ... कर्नेल पहले से ही सक्रिय रूप से जीयूआई का उपयोग कर रहा है, इसलिए अब यह हिस्सा भी सबसे नीचे होगा। मैं अस्थायी रूप से आशा करता हूं।

कुल मिलाकर

मेरी राय में, इस दिशा में निर्धारित किए गए कार्यों को आम तौर पर हल किया गया है। बेशक, पूर्णता की कोई सीमा नहीं है, लेकिन, जैसा कि मुझे लगता है, इंटरफ़ेस ने हैकर से सार्वभौमिक तक एक ठोस कदम उठाया है।