بروتوكول النظام الأساسي لنظام النوافذ X

يُعدّ البروتوكول الأساسي لنظام X Window ^{[ 1 ] [ 2 ] [ 3 ]} البروتوكولَ الأساسي لهذا النظام ، وهو نظام نوافذ شبكي لعرض الصور النقطية ، يُستخدم لبناء واجهات المستخدم الرسومية على أنظمة يونكس ، والأنظمة الشبيهة بيونكس ، وأنظمة تشغيل أخرى . يعتمد نظام X Window على نموذج العميل والخادم : حيث يتحكم خادم واحد في أجهزة الإدخال/الإخراج ، مثل الشاشة ولوحة المفاتيح والفأرة ؛ وتعمل جميع برامج التطبيقات كعملاء ، تتفاعل مع المستخدم ومع العملاء الآخرين عبر الخادم. وينظم البروتوكول الأساسي لنظام X Window هذا التفاعل. توجد بروتوكولات أخرى مرتبطة بنظام X Window، بعضها مبني على البروتوكول الأساسي لنظام X Window، والبعض الآخر كبروتوكولات منفصلة.

في البروتوكول الأساسي لنظام X Window، تُرسل أربعة أنواع فقط من الحزم، بشكل غير متزامن ، عبر الشبكة: الطلبات، والردود، والأحداث، والأخطاء. يرسل العميل الطلبات إلى الخادم ليطلب منه تنفيذ عملية معينة (مثل إنشاء نافذة جديدة) وإرسال البيانات التي يحتفظ بها. يرسل الخادم الردود لتوفير هذه البيانات. يرسل الخادم الأحداث لإعلام العملاء بنشاط المستخدم أو أي أحداث أخرى تهمهم. أما الأخطاء فهي حزم يرسلها الخادم لإعلام العميل بالأخطاء التي حدثت أثناء معالجة طلباته. قد تُنتج الطلبات ردودًا وأحداثًا وأخطاءً؛ وبخلاف ذلك، لا يفرض البروتوكول ترتيبًا محددًا لإرسال الحزم عبر الشبكة. توجد بعض الإضافات للبروتوكول الأساسي، ولكل منها طلباتها وردودها وأحداثها وأخطاؤها الخاصة.

نشأت X في معهد ماساتشوستس للتكنولوجيا عام 1984 (موقعها الحالي)صدر الإصدار X11 في سبتمبر 1987. وضع مصمماه، بوب شيفلر وجيم جيتيس، مبدأً أساسياً منذ البداية مفاده أن بروتوكوله الجوهري هو "إنشاء آلية، لا سياسة". ونتيجةً لذلك، لا يُحدد البروتوكول الجوهري التفاعل بين العملاء، ولا بين العميل والمستخدم. تخضع هذه التفاعلات لمواصفات منفصلة، ^{​​[ 4 ]} مثل مواصفات ICCCM و freedesktop.org ، ويتم تطبيقها عادةً تلقائيًا باستخدام مجموعة أدوات محددة .

يتم التواصل بين الخادم والعملاء عبر تبادل الحزم من خلال قناة اتصال . يُنشئ العميل الاتصال (لا يُحدد البروتوكول كيفية بدء تشغيل العميل). كما يُرسل العميل الحزمة الأولى، التي تحتوي على ترتيب البايتات المستخدم ومعلومات حول إصدار البروتوكول ونوع المصادقة التي يتوقع العميل أن يستخدمها الخادم. يرد الخادم بإرسال حزمة تُفيد بقبول الاتصال أو رفضه، أو بطلب مصادقة إضافية . في حال قبول الاتصال، تحتوي حزمة القبول على بيانات يستخدمها العميل في التفاعل اللاحق مع الخادم.

بعد إنشاء الاتصال، يتم تبادل أربعة أنواع من الحزم بين العميل والخادم عبر القناة:

1. الطلب: يطلب العميل معلومات من الخادم أو يطلب منه تنفيذ إجراء ما.
2. الرد: يستجيب الخادم للطلب. لا تُولّد جميع الطلبات ردودًا.
3. الحدث: يقوم الخادم بإبلاغ العميل بحدث ما، مثل إدخال لوحة المفاتيح أو الماوس، أو تحريك نافذة أو تغيير حجمها أو عرضها، وما إلى ذلك.
4. خطأ: يرسل الخادم حزمة خطأ إذا كان الطلب غير صالح. ونظرًا لأن الطلبات تُوضع في قائمة انتظار، فقد لا تُرسل حزم الخطأ الناتجة عن الطلب فورًا.

تختلف أطوال حزم الطلب والرد، بينما يبلغ طول حزم الأحداث والأخطاء 32 بايت ثابتة .

يقوم الخادم بترقيم حزم الطلبات بالتسلسل فور استلامها: يُرقم الطلب الأول من العميل بالرقم 1، والثاني بالرقم 2، وهكذا. تُضمّن أقل 16 بتًا أهميةً من الرقم التسلسلي للطلب في حزم الرد والخطأ الناتجة عن الطلب، إن وُجدت. كما تُضمّن أيضًا في حزم الأحداث للإشارة إلى الرقم التسلسلي للطلب الذي يُعالجه الخادم حاليًا أو الذي انتهى من معالجته للتو.

ما يُعرف عادةً باسم "نافذة" في معظم واجهات المستخدم الرسومية، يُسمى " نافذة رئيسية" في نظام X Window. ويُستخدم مصطلح "نافذة" أيضًا للإشارة إلى النوافذ الموجودة داخل نافذة أخرى، أي النوافذ الفرعية لنافذة رئيسية . ويمكن إنشاء العناصر الرسومية ، مثل الأزرار والقوائم والأيقونات ، باستخدام النوافذ الفرعية.

يمكن للعميل طلب إنشاء نافذة. وبشكل أدق، يمكنه طلب إنشاء نافذة فرعية لنافذة موجودة. ونتيجة لذلك، تُرتّب النوافذ التي ينشئها العملاء في شكل شجرة (هرمية). جذر هذه الشجرة هو النافذة الجذرية ، وهي نافذة خاصة يُنشئها الخادم تلقائيًا عند بدء التشغيل. جميع النوافذ الأخرى هي نوافذ فرعية مباشرة أو غير مباشرة للنافذة الجذرية. النوافذ ذات المستوى الأعلى هي النوافذ الفرعية المباشرة للنافذة الجذرية. من الواضح أن النافذة الجذرية بحجم سطح المكتب الافتراضي، وتقع خلف جميع النوافذ الأخرى.

لا يُضمن دائمًا الحفاظ على محتوى النافذة بمرور الوقت. على وجه الخصوص، قد يُفقد محتوى النافذة عند نقلها أو تغيير حجمها أو تغطيتها بنوافذ أخرى، أو عند جعلها غير مرئية كليًا أو جزئيًا. ويُفقد المحتوى تحديدًا إذا لم يحتفظ خادم X بنسخة احتياطية منه. يمكن للعميل طلب الاحتفاظ بهذه النسخة الاحتياطية، ولكن ليس على الخادم التزام بذلك. لذا، لا يمكن للعملاء افتراض وجود نسخة احتياطية محفوظة. إذا كان جزء مرئي من النافذة يحتوي على محتوى غير محدد، يُرسل حدث لإعلام العميل بضرورة إعادة رسم محتوى النافذة.

لكل نافذة مجموعة من السمات المرتبطة بها ، مثل هندسة النافذة (الحجم والموضع)، وصورة الخلفية، وما إذا كان قد تم طلب وحدة تخزين احتياطية لها، وما إلى ذلك. يتضمن البروتوكول طلبات من العميل لفحص وتغيير سمات النافذة.

يمكن أن تكون النوافذ InputOutputإما معروضة على الشاشة أو غير معروضة InputOnly. InputOutputيمكن عرض النوافذ على الشاشة وتُستخدم للرسم. أما InputOnlyالنوافذ الأخرى فلا تُعرض على الشاشة أبدًا وتُستخدم فقط لاستقبال المدخلات.

يتم إنشاء الإطار الزخرفي وشريط العنوان (الذي قد يتضمن أزرارًا) المحيطين بالنوافذ عادةً بواسطة مدير النوافذ ، وليس بواسطة البرنامج الذي أنشأ النافذة. كما يتولى مدير النوافذ معالجة المدخلات المتعلقة بهذه العناصر، مثل تغيير حجم النافذة عند نقر المستخدم وسحب إطارها. عادةً ما يتعامل البرنامج مع النافذة التي أنشأها متجاهلاً التغييرات التي يُجريها مدير النوافذ. ومن التغييرات التي يجب مراعاتها أن مديري النوافذ الذين يُعيدون توجيه النوافذ، والذين تُعدّ معظم مديري النوافذ الحديثة منهم، يُغيّرون النافذة الأب للنوافذ ذات المستوى الأعلى إلى نافذة ليست هي النافذة الجذرية. من وجهة نظر البروتوكول الأساسي، يُعتبر مدير النوافذ برنامجًا، لا يختلف عن التطبيقات الأخرى.

يمكن الحصول على بيانات حول نافذة ما عن طريق تشغيل xwininfoالبرنامج. عند تمرير -treeوسيط سطر الأوامر ، يعرض هذا البرنامج شجرة النوافذ الفرعية للنافذة، بالإضافة إلى معرّفاتها وبياناتها الهندسية.

خريطة البكسل هي منطقة في الذاكرة تُستخدم للرسم. على عكس النوافذ، لا تُعرض خرائط البكسل تلقائيًا على الشاشة. مع ذلك، يمكن نقل محتوى خريطة البكسل (أو جزء منه) إلى نافذة والعكس صحيح. يتيح ذلك استخدام تقنيات مثل التخزين المؤقت المزدوج . معظم العمليات الرسومية التي يمكن إجراؤها على النوافذ يمكن إجراؤها أيضًا على خرائط البكسل.

تُسمى النوافذ والصور النقطية مجتمعةً بالرسومات ، وتُخزَّن بيانات محتواها على الخادم. ومع ذلك، يمكن للعميل طلب نقل محتوى الرسمة من الخادم إليه أو العكس.

يمكن للعميل طلب عدد من العمليات الرسومية، مثل مسح منطقة، ونسخ منطقة إلى أخرى، ورسم النقاط والخطوط والمستطيلات والنصوص. وباستثناء المسح، فإن جميع العمليات متاحة على جميع العناصر الرسومية، سواء كانت نوافذ أو صور نقطية.

تتضمن معظم طلبات العمليات الرسومية سياقًا رسوميًا ، وهو عبارة عن بنية تحتوي على معلمات العمليات الرسومية. يشمل السياق الرسومي لون المقدمة، ولون الخلفية، ونوع خط النص، ومعلمات رسومية أخرى. عند طلب عملية رسومية، يُرفق العميل سياقًا رسوميًا. لا تؤثر جميع معلمات السياق الرسومي على العملية؛ فعلى سبيل المثال، لا يؤثر نوع الخط على رسم خط.

يحدد البروتوكول الأساسي استخدام الخطوط المُخزّنة على الخادم. تُخزّن هذه الخطوط كملفات ، ويصل إليها الخادم إما مباشرةً عبر نظام الملفات المحلي أو عبر الشبكة من خلال برنامج آخر يُسمى خادم الخطوط . يمكن للعملاء طلب قائمة الخطوط المتاحة للخادم، وطلب تحميل خط معين (إن لم يكن مُحمّلاً بالفعل) أو إلغاء تحميله (إن لم يكن مستخدمًا من قِبل عملاء آخرين). كما يمكن للعميل طلب معلومات عامة حول الخط (مثل تصاعد الخط) والمسافة التي يشغلها نص معين عند رسمه بخط معين.

أسماء الخطوط عبارة عن سلاسل نصية عشوائية على مستوى بروتوكول X الأساسي. تحدد اصطلاحات وصف الخطوط المنطقية في X ^{[ 5 ]} كيفية تسمية الخطوط وفقًا لخصائصها. كما تحدد هذه الاصطلاحات قيم الخصائص الاختيارية التي يمكن إضافتها إلى الخطوط.

يعرض البرنامج xlsfontsقائمة الخطوط المخزنة على الخادم. xfontselكما يعرض رموز الخطوط، ويتيح للمستخدم اختيار اسم الخط للصقه في نافذة أخرى.

يُعتبر استخدام الخطوط من جانب الخادم حاليًا أمرًا مُهملًا لصالح الخطوط من جانب العميل. ^{[ 6 ]} يتم عرض هذه الخطوط بواسطة العميل، وليس بواسطة الخادم، بدعم من مكتبات Xft أو Cairo وامتداد XRender . لا توجد مواصفات خاصة بالخطوط من جانب العميل في البروتوكول الأساسي.

تُخزَّن جميع البيانات المتعلقة بالنوافذ، والصور النقطية، والخطوط، وما إلى ذلك، على الخادم. يعرف العميل مُعرِّفات هذه العناصر - وهي أعداد صحيحة يستخدمها كأسماء لها عند التفاعل مع الخادم. على سبيل المثال، إذا رغب العميل في إنشاء نافذة، فإنه يطلب من الخادم إنشاء نافذة بمُعرِّف مُحدد. يمكن للعميل استخدام هذا المُعرِّف لاحقًا لطلب، على سبيل المثال، رسم نص في النافذة. العناصر التالية موجودة على الخادم ويعرفها العميل من خلال مُعرِّف رقمي:

• Window
• Pixmap
• Font
• Colormap(جدول الألوان، الموصوف أدناه)
• Graphic context

تُسمى هذه الكائنات بالموارد . عندما يطلب العميل إنشاء أحد هذه الموارد، فإنه يُحدد أيضًا مُعرّفًا لها. على سبيل المثال، لإنشاء نافذة جديدة، يُحدد العميل سمات النافذة (الرئيسية، والعرض، والارتفاع، وما إلى ذلك) والمُعرّف الذي سيربطه بها.

المعرّفات عبارة عن أعداد صحيحة من 32 بت، حيث تكون البتات الثلاثة الأكثر أهمية فيها مساوية للصفر. يمتلك كل عميل مجموعة معرّفات خاصة به يمكنه استخدامها لإنشاء موارد جديدة. يحدد الخادم هذه المجموعة من خلال عددين صحيحين مُضمّنين ​​في حزمة القبول (الحزمة التي يرسلها إلى العميل لإبلاغه بقبول الاتصال). يختار العملاء المعرّفات ضمن هذه المجموعة بطريقة لا تتعارض معها: فلا يمكن أن يحمل عنصران من بين النوافذ، أو الصور النقطية، أو الخطوط، أو خرائط الألوان، أو سياقات الرسومات، نفس المعرّف.

بمجرد إنشاء مورد، يستخدم العميل معرّفه لطلب عمليات عليه من الخادم. بعض هذه العمليات تؤثر على المورد نفسه (مثل طلبات نقل النوافذ)؛ بينما تطلب عمليات أخرى بيانات المورد المخزنة على الخادم (مثل طلبات خصائص النوافذ).

المعرّفات فريدة للخادم، وليست حصرية للعميل؛ فعلى سبيل المثال، لا يوجد نافذتان لهما نفس المعرّف، حتى لو أنشأهما عميلان مختلفان. يستطيع العميل الوصول إلى أي كائن باستخدام معرّفه. وبشكل خاص، يمكنه أيضًا الوصول إلى الموارد التي أنشأها أي عميل آخر، حتى لو كانت معرّفاته خارج مجموعة المعرّفات التي يمكنه إنشاؤها.

نتيجةً لذلك، يمكن لعميلين متصلين بنفس الخادم استخدام نفس المعرّف للإشارة إلى نفس المورد. على سبيل المثال، إذا أنشأ عميل نافذةً بمعرّف معين 0x1e00021ومرر هذا الرقم 0x1e00021إلى تطبيق آخر (بأي وسيلة متاحة، كتخزين هذا الرقم في ملف يمكن للتطبيق الآخر الوصول إليه أيضًا)، فسيكون بإمكان هذا التطبيق الآخر العمل على نفس النافذة. تستغل نسخة X من Ghostview هذه الإمكانية، على سبيل المثال : حيث يُنشئ هذا البرنامج نافذةً فرعية، ويخزن معرّفها في متغير بيئي ، ثم يستدعي Ghostscript ؛ فيقوم هذا البرنامج برسم محتوى ملف PostScript لعرضه في هذه النافذة. ^{[ 7 ]}

تُحذف الموارد عادةً عندما يُغلق العميل الذي أنشأها الاتصال مع الخادم. ومع ذلك، قبل إغلاق الاتصال، يمكن للعميل أن يطلب من الخادم عدم حذفها.

الأحداث عبارة عن حزم بيانات يرسلها الخادم إلى العميل لإبلاغه بحدوث أمر قد يهم العميل. على سبيل المثال، يُرسل حدث عند ضغط المستخدم على مفتاح أو نقره على زر الفأرة. ولا تقتصر استخدامات الأحداث على إدخال البيانات فقط، بل تُرسل أيضًا للإشارة إلى إنشاء نوافذ فرعية جديدة ضمن نافذة معينة.

كل حدث مرتبط بنافذة معينة. على سبيل المثال، إذا نقر المستخدم عندما يكون المؤشر داخل نافذة، فسيكون الحدث مرتبطًا بتلك النافذة. تحتوي حزمة الحدث على مُعرّف تلك النافذة.

يمكن للعميل أن يطلب من الخادم إرسال حدث إلى عميل آخر؛ ويُستخدم هذا للتواصل بين العملاء. على سبيل المثال، يتم إنشاء هذا الحدث عندما يطلب عميل النص المحدد حاليًا: يُرسل هذا الحدث إلى العميل الذي يتعامل حاليًا مع النافذة التي تحتوي على النص المحدد.

يُرسل هذا Exposeالحدث عند حذف جزء من نافذة ما وظهور محتواها. قد يُحذف محتوى النافذة في بعض الحالات، كأن تكون النافذة مغطاة ولا يحتفظ الخادم بنسخة احتياطية منها. يُنشئ الخادم حدثًا Exposeلإعلام العميل بضرورة إعادة رسم جزء من النافذة.

تُرسل معظم أنواع الأحداث فقط إذا أبدى العميل اهتمامًا بها مسبقًا. وذلك لأن العملاء قد يهتمون بأنواع محددة من الأحداث فقط. على سبيل المثال، قد يهتم العميل بالأحداث المتعلقة بلوحة المفاتيح دون الأحداث المتعلقة بالفأرة. مع ذلك، تُرسل بعض أنواع الأحداث إلى العملاء حتى لو لم يطلبوها تحديدًا.

يُحدد العملاء أنواع الأحداث التي يرغبون في تلقيها من خلال ضبط سمة معينة في النافذة. على سبيل المثال، لإعادة رسم نافذة بعد حذف محتواها، يجب أن يتلقى العميل أحداثًا Exposeتُعلمه بضرورة إعادة رسم النافذة. مع ذلك، لن تُرسل Exposeالأحداث إلى العميل إلا إذا كان قد أبدى اهتمامه بها مسبقًا، وذلك من خلال ضبط سمة قناع الأحداث في النافذة بشكل مناسب.

يمكن لعملاء مختلفين طلب أحداث على نفس النافذة، بل ويمكنهم تعيين أقنعة أحداث مختلفة عليها. على سبيل المثال، قد يطلب عميل أحداث لوحة المفاتيح فقط على نافذة معينة، بينما يطلب عميل آخر أحداث الفأرة فقط على نفس النافذة. هذا ممكن لأن الخادم يحتفظ بقناع أحداث منفصل لكل عميل، وذلك لكل نافذة. مع ذلك، توجد بعض أنواع الأحداث التي لا يمكن تحديدها إلا من قِبل عميل واحد في كل مرة لكل نافذة. على وجه الخصوص، تُبلغ هذه الأحداث عن نقرات زر الفأرة وبعض التغييرات المتعلقة بإدارة النوافذ.

يعرض البرنامج xevالأحداث المتعلقة بنافذة معينة. وعلى وجه الخصوص، xev -id WIDيطلب البرنامج جميع الأحداث الممكنة المتعلقة بنافذة ذات مُعرّف معين WIDويطبعها.

فيما يلي مثال محتمل للتفاعل بين خادم وبرنامج يُنشئ نافذة تحتوي على مربع أسود، ثم يُغلق عند الضغط على مفتاح. في هذا المثال، لا يُرسل الخادم أي رد لأن طلبات العميل لا تُولّد ردودًا، وقد تُؤدي هذه الطلبات إلى حدوث أخطاء.

1. يقوم العميل بفتح الاتصال مع الخادم ويرسل الحزمة الأولية التي تحدد ترتيب البايتات الذي يستخدمه.
2. يقبل الخادم الاتصال (لا يوجد ترخيص في هذا المثال) عن طريق إرسال حزمة مناسبة، والتي تحتوي على معلومات أخرى مثل معرف النافذة الجذرية (على سبيل المثال، 0x0000002b) والمعرفات التي يمكن للعميل إنشاؤها.
3. يطلب العميل إنشاء سياق رسومي افتراضي بمعرف 0x00200000(هذا الطلب، مثل الطلبات الأخرى في هذا المثال، لا يُولّد ردودًا من الخادم).
4. يطلب العميل من الخادم إنشاء نافذة من المستوى الأعلى (أي أنه يحدد النافذة الأصلية لتكون النافذة الجذرية 0x0000002b) بمعرف 0x00200001، وحجم 200x200 ، وموضع (10،10)، وما إلى ذلك.
5. يطلب العميل تغييرًا في خصائص النافذة 0x00200001، ويحدد أنه مهتم بتلقي Exposeالأحداث KeyPress.
6. يطلب العميل 0x00200001تحديد موقع النافذة (عرضها على الشاشة).
7. عندما تصبح النافذة مرئية ويجب رسم محتواها، يرسل الخادم Exposeحدثًا إلى العميل
8. استجابةً لهذا الحدث، يطلب العميل رسم مربع عن طريق إرسال PolyFillRectangleطلب يتضمن نافذة 0x00200001وسياقًا رسوميًا.0x00200000

إذا تم تغطية النافذة بنافذة أخرى ثم تم كشفها مرة أخرى، بافتراض عدم صيانة المخزن الخلفي:

1. يرسل الخادم Exposeحدثًا آخر لإبلاغ العميل بضرورة إعادة رسم النافذة.
2. يقوم العميل بإعادة رسم النافذة عن طريق إرسال PolyFillRectangleطلب

في حالة الضغط على مفتاح:

1. يرسل الخادم KeyPressحدثًا إلى العميل لإعلامه بأن المستخدم قد ضغط على مفتاح
2. يتفاعل العميل بشكل مناسب (في هذه الحالة، يتم إنهاء العملية).

على مستوى البروتوكول، يُمثَّل اللون بعدد صحيح غير مُوقَّع من 32 بت، يُسمى قيمة البكسل . وتؤثر العناصر التالية على تمثيل الألوان:

1. عمق اللون
2. خريطة الألوان ، وهي عبارة عن جدول يحتوي على قيم شدة اللون الأحمر والأخضر والأزرق
3. النوع المرئي ، الذي يحدد كيفية استخدام الجدول لتمثيل الألوان

في أبسط الحالات، تكون خريطة الألوان عبارة عن جدول يحتوي على ثلاثية RGB في كل صف. تمثل قيمة البكسل xاللون الموجود في xالصف رقم n من الجدول. إذا كان بإمكان المستخدم تغيير قيم خريطة الألوان، يتم تحديد هذا التمثيل بواسطة PseudoColorالفئة المرئية . أما الفئة المرئية الأخرى StaticColorفهي مشابهة، ولكن لا يمكن للمستخدم تغيير قيم خريطة الألوان.

يوجد ستة أنواع مرئية ممكنة، كل منها يحدد طريقة مختلفة لتمثيل ثلاثية RGB بقيمة بكسل. PseudoColorيوجد StaticColorنوعان منها، وهما GrayScaleو StaticGray، ويختلفان في أنهما يعرضان درجات اللون الرمادي فقط.

تختلف الفئتان المرئيتان المتبقيتان عن الفئات المذكورة أعلاه لأنهما تقسمان قيم البكسل إلى ثلاثة أجزاء وتستخدمان ثلاثة جداول منفصلة لشدة اللون الأحمر والأخضر والأزرق. ووفقًا لهذا التمثيل اللوني، يتم تحويل قيمة البكسل إلى ثلاثية RGB كما يلي:

1. تُعتبر قيمة البكسل سلسلة من البتات
2. ينقسم هذا التسلسل إلى ثلاثة أجزاء
3. تُعتبر كل من هذه الأجزاء الثلاثة من البتات عددًا صحيحًا وتُستخدم كمؤشر للعثور على قيمة في كل من الجداول الثلاثة المنفصلة

تتطلب هذه الآلية أن تتكون خريطة الألوان من ثلاثة جداول منفصلة، ​​جدول لكل لون أساسي . ومع ذلك، تبقى نتيجة التحويل عبارة عن ثلاث قيم للشدة. الفئات المرئية التي تستخدم هذا التمثيل هي [اسم الفئة 1] DirectColorو[ TrueColorاسم الفئة 2]، وتختلف فيما إذا كان بإمكان المستخدم تغيير خرائط الألوان أم لا.

تتطلب هذه الآليات الست لتمثيل الألوان بقيم البكسل بعض المعاملات الإضافية للعمل. تُجمع هذه المعاملات في نوع مرئي ، يحتوي على فئة مرئية ومعاملات أخرى لتمثيل الألوان. يمتلك كل خادم مجموعة ثابتة من الأنواع المرئية، يرتبط كل منها بمعرف رقمي. هذه المعرفات عبارة عن أعداد صحيحة غير مُوقّعة من 32 بت، ولكنها لا تختلف بالضرورة عن معرفات الموارد أو الذرات.

عند قبول اتصال العميل، تحتوي حزمة القبول المرسلة من الخادم على سلسلة من الكتل، تحتوي كل منها على معلومات حول شاشة واحدة. لكل شاشة، تحتوي الكتلة الخاصة بها على قائمة بكتل أخرى، كل منها مرتبط بعمق لوني محدد تدعمه الشاشة. لكل عمق مدعوم، تحتوي هذه القائمة على قائمة بأنواع العرض المرئي. ونتيجة لذلك، ترتبط كل شاشة بعدد من الأعماق الممكنة، ويرتبط كل عمق من أعماق كل شاشة بعدد من أنواع العرض المرئي الممكنة. يمكن استخدام نوع عرض مرئي معين لأكثر من شاشة وبأعماق مختلفة.

تحتوي حزمة القبول لكل نوع مرئي على مُعرّفه ومعاملاته الفعلية (الفئة المرئية، إلخ). يحتفظ العميل بهذه المعلومات، إذ لا يمكنه طلبها لاحقًا. علاوة على ذلك، لا يمكن للعملاء تغيير الأنواع المرئية أو إنشاء أنواع جديدة. تتضمن طلبات إنشاء نافذة جديدة عمق ومعرف النوع المرئي المستخدم لتمثيل ألوان هذه النافذة.

تُستخدم خرائط الألوان بغض النظر عما إذا كانت وحدة التحكم بالشاشة (مثل بطاقة الرسومات ) تستخدم لوحة ألوان ، وهي جدول يُستخدم أيضًا لتمثيل الألوان. تستخدم الخوادم خرائط الألوان حتى لو لم تكن وحدة التحكم تستخدم لوحة ألوان. عندما تستخدم وحدة التحكم لوحات ألوان، لا يمكن تثبيت سوى عدد محدود من خرائط الألوان. على وجه الخصوص، يتم تثبيت خريطة ألوان عندما تعرض وحدة التحكم الألوان وفقًا لها. يمكن للعميل أن يطلب من الخادم تثبيت خريطة ألوان. ومع ذلك، قد يتطلب ذلك إلغاء تثبيت خريطة ألوان أخرى: والنتيجة هي أن النوافذ التي تستخدم خريطة الألوان التي تم إلغاء تثبيتها لا تُعرض باللون الصحيح، وهو تأثير يُعرف باسم وميض الألوان أو تكنيكولور . يمكن حل هذه المشكلة باستخدام خرائط الألوان القياسية ، وهي خرائط ألوان ذات ارتباط متوقع بين قيم البكسل والألوان. بفضل هذه الخاصية، يمكن استخدام خرائط الألوان القياسية بواسطة تطبيقات مختلفة.

تخضع عملية إنشاء خرائط الألوان لاتفاقية ICCCM . وتخضع خرائط الألوان القياسية لاتفاقية ICCCM ومواصفات Xlib .

يُعد نظام إدارة ألوان X (xcms) جزءًا من نظام ألوان X. وقد طُرح هذا النظام مع الإصدار الخامس من X11R6 عام 1991. يتألف هذا النظام من عدة ميزات إضافية في مكتبة xlib، موجودة ضمن سلسلة وظائف Xcms*. يُعرّف هذا النظام مخططات ألوان مستقلة عن الجهاز، والتي يُمكن تحويلها إلى أنظمة ألوان RGB خاصة بالجهاز. يتكون النظام من وظائف Xcms* في مكتبة xlib، بالإضافة إلى اتفاقية توصيف ألوان أجهزة X (XDCCC) التي تُحدد كيفية تحويل أنظمة الألوان المستقلة عن الجهاز إلى أنظمة ألوان RGB خاصة بالجهاز. يدعم هذا النظام أنظمة الألوان CIEXYZ و xyY و CIELUV و CIELAB ، بالإضافة إلى نظام TekHVC . تمت أرشفة هذه الصفحة بتاريخ 5 أكتوبر 2011 على موقع Wayback Machine .

الذرات هي أعداد صحيحة من 32 بت تمثل سلاسل نصية . وقد أدخل مصممو البروتوكول الذرات لأنها تمثل السلاسل النصية بحجم قصير وثابت: ^{[ 8 ]} فبينما قد تكون السلسلة النصية طويلة كيفما كانت، فإن الذرة دائمًا ما تكون عددًا صحيحًا من 32 بت. وقد استُغلّ اختصار الذرات من خلال إلزام استخدامها في أنواع الحزم التي يُحتمل إرسالها عدة مرات بنفس السلاسل النصية؛ مما يؤدي إلى استخدام أكثر كفاءة للشبكة. كما استُغلّ الحجم الثابت للذرات من خلال تحديد حجم ثابت للأحداث، وهو 32 بايت: إذ يمكن للحزم ذات الحجم الثابت أن تحتوي على ذرات، بينما لا يمكنها أن تحتوي على سلاسل نصية طويلة.

باختصار، الذرات هي مُعرّفات للسلاسل النصية المخزنة على الخادم. وهي تُشبه مُعرّفات الموارد (مثل Windows وPixmaps وغيرها)، لكنها تختلف عنها في جانبين. أولًا، يختار الخادم مُعرّفات الذرات، وليس العميل. بمعنى آخر، عندما يطلب العميل إنشاء ذرة جديدة، فإنه يُرسل إلى الخادم السلسلة النصية المراد تخزينها فقط، وليس مُعرّفها؛ إذ يختار الخادم هذا المُعرّف ويرسله كردٍّ إلى العميل. أما الاختلاف الثاني المهم بين الموارد والذرات، فهو أن الذرات غير مرتبطة بالعملاء. فبمجرد إنشائها، تبقى الذرة موجودة حتى يُغلق الخادم أو يُعاد تشغيله (وهذا ليس السلوك الافتراضي للموارد).

الذرات هي مُعرّفات، وبالتالي فهي فريدة. مع ذلك، قد تتطابق الذرة مع مُعرّف المورد. يُطلق على السلسلة النصية المرتبطة بالذرة اسم الذرة . لا يُمكن تغيير اسم الذرة بعد إنشائها، ولا يُمكن أن تحمل ذرتان الاسم نفسه. ونتيجةً لذلك، يُستخدم اسم الذرة عادةً للإشارة إليها: "الذرة ABCD" تعني، بتعبير أدق، "الذرة التي السلسلة النصية المرتبطة بها هي ABCD..." أو "الذرة التي اسمها ABCD...". يُمكن للعميل طلب إنشاء ذرة جديدة، كما يُمكنه طلب الذرة (المُعرّف) لسلسلة نصية مُحددة. بعض الذرات مُعرّفة مُسبقًا (أنشأها الخادم بمُعرّف وسلسلة نصية مُحددين).

تُستخدم الذرات لأغراض متعددة، معظمها يتعلق بالاتصال بين عملاء مختلفين متصلين بنفس الخادم. وعلى وجه الخصوص، تُستخدم الذرات بالاقتران مع خصائص النوافذ، الموضحة أدناه.

يمكن طباعة قائمة بجميع الذرات الموجودة في الخادم باستخدام البرنامج xlsatoms. وعلى وجه الخصوص، يطبع هذا البرنامج كل ذرة (المعرف، أي رقم) مع اسمها (السلسلة المرتبطة بها).

لكل نافذة مجموعة محددة مسبقًا من السمات ومجموعة من الخصائص، تُخزَّن جميعها على الخادم ويمكن للعملاء الوصول إليها عبر طلبات مناسبة. السمات هي بيانات حول النافذة، مثل حجمها وموقعها ولون خلفيتها، وما إلى ذلك. أما الخصائص فهي بيانات عشوائية مُلحقة بالنافذة. على عكس السمات، لا تحمل الخصائص أي معنى على مستوى بروتوكول X الأساسي. يمكن للعميل تخزين أي بيانات في خاصية من خصائص النافذة.

تتميز الخاصية باسم ونوع وقيمة. تشبه الخصائص المتغيرات في لغات البرمجة الإجرائية ، حيث يمكن للمستخدم إنشاء خاصية جديدة باسم ونوع محددين وتخزين قيمة فيها. ترتبط الخصائص بالنوافذ: يمكن أن توجد خاصيتان بنفس الاسم في نافذتين مختلفتين مع اختلاف النوع والقيمة.

اسم الخاصية ونوعها وقيمتها عبارة عن سلاسل نصية؛ أو بتعبير أدق، هي ذرات، أي سلاسل نصية مخزنة على الخادم ويمكن للعملاء الوصول إليها عبر معرّفات. يستطيع تطبيق العميل الوصول إلى خاصية معينة باستخدام معرّف الذرة التي تحتوي على اسم الخاصية.

تُستخدم الخصائص في الغالب للتواصل بين العملاء. على سبيل المثال، تُستخدم الخاصية المسماة WM_NAME(الخاصية المسماة بواسطة العنصر المرتبط بها السلسلة النصية "WM_NAME") لتخزين اسم النوافذ. عادةً ما تقرأ برامج إدارة النوافذ هذه الخاصية لعرض اسم النوافذ في شريط العنوان.

تستخدم بعض أنواع الاتصال بين العملاء خصائص النافذة الجذرية. على سبيل المثال، وفقًا لمواصفات مدير النوافذ في برنامج freedesktop ، ^{[ 9 ]} يجب على مديري النوافذ تخزين مُعرّف النافذة النشطة حاليًا في الخاصية المسماة _NET_ACTIVE_WINDOWللنافذة الجذرية. كما تُخزّن موارد X ، التي تحتوي على معلمات البرامج، في خصائص النافذة الجذرية؛ وبهذه الطريقة، يمكن لجميع العملاء الوصول إليها، حتى لو كانوا يعملون على أجهزة كمبيوتر مختلفة.

يقوم البرنامج xpropبطباعة خصائص نافذة معينة؛ xprop -rootويطبع اسم ونوع وقيمة كل خاصية من خصائص النافذة الجذرية.

في نظام X Window، يرتبط كل مفتاح فعلي برقم يتراوح بين 8 و255، يُسمى رمز المفتاح . يُحدد رمز المفتاح المفتاح نفسه فقط، وليس حرفًا أو مصطلحًا معينًا (مثل "صفحة لأعلى") من بين الأحرف أو المصطلحات المطبوعة عليه. يُحدد كل حرف أو مصطلح برمز خاص به . بينما يعتمد رمز المفتاح على المفتاح المضغوط فقط، قد يعتمد الرمز الخاص به، على سبيل المثال، على ما إذا كان مفتاح Shift أو مفتاح تعديل آخر قد تم الضغط عليه أيضًا.

عند الضغط على مفتاح أو تحريره، يرسل الخادم أحداثًا من نوع معين KeyPressإلى KeyReleaseالعملاء المناسبين. تتضمن هذه الأحداث ما يلي:

1. رمز المفتاح المضغوط
2. الحالة الحالية للمفاتيح المعدلة (Shift، Control، إلخ) وأزرار الماوس

لذا، يرسل الخادم رمز المفتاح وحالة المُعدِّل دون محاولة ترجمتهما إلى حرف مُحدد. تقع مسؤولية هذا التحويل على عاتق العميل. على سبيل المثال، قد يتلقى العميل حدثًا يُفيد بالضغط على مفتاح مُعين أثناء الضغط على مفتاح Shift. إذا كان هذا المفتاح يُولِّد عادةً الحرف "a"، فإن العميل (وليس الخادم) هو من يربط هذا الحدث بالحرف "A".

بينما يقوم العميل بتحويل رموز المفاتيح إلى رموزها، يحتفظ الخادم بالجدول الذي يمثل هذا الربط. يتيح تخزين هذا الجدول في مكان مركزي الوصول إليه لجميع العملاء. عادةً ما يطلب العملاء هذا الربط ويستخدمونه لفك تشفير حقلَي رمز المفتاح والمُعدِّلات في حدث المفتاح إلى رمز مفتاح. مع ذلك، يمكن للعملاء أيضًا تغيير هذا الربط متى شاؤوا.

المفتاح المُعدِّل هو مفتاح يُغيِّر، عند الضغط عليه، وظيفة المفاتيح الأخرى. من المفاتيح المُعدِّلة الشائعة مفتاح Shift : فعند الضغط على المفتاح الذي يُنتج عادةً حرف "a" صغيرًا مع مفتاح Shift، يُنتج حرف "A" كبيرًا. ومن المفاتيح المُعدِّلة الشائعة الأخرى مفاتيح "Control" و"Alt" و"Meta".

يدعم خادم X ثمانية مفاتيح تعديل كحد أقصى. مع ذلك، يمكن ربط كل مفتاح تعديل بأكثر من مفتاح واحد. هذا ضروري لأن العديد من لوحات المفاتيح تحتوي على مفاتيح مكررة لبعض مفاتيح التعديل. على سبيل المثال، تحتوي العديد من لوحات المفاتيح على مفتاحي "Shift" (أحدهما على اليسار والآخر على اليمين). ينتج هذان المفتاحان رمزين مختلفين عند الضغط عليهما، لكن خادم X يربط كليهما بمفتاح التعديل "Shift".

يحتفظ خادم X بقائمة رموز المفاتيح التي يعتبرها لكل مُعدِّل من المُعدِّلات الثمانية. على سبيل المثال، إذا كانت قائمة المُعدِّل الأول (مُعدِّل "Shift") تحتوي على رمز المفتاح 0x37، فإن المفتاح الذي يُنتج هذا الرمز 0x37يُعتبر مفتاح Shift من قِبل خادم X.

يحتفظ خادم X بقوائم تعيينات المفاتيح المعدلة، ولكن يمكن لأي عميل تغييرها. على سبيل المثال، يمكن للعميل طلب إضافة مفتاح "F1 " إلى قائمة مفاتيح "Shift" المعدلة. من هذه اللحظة، يتصرف هذا المفتاح كأي مفتاح Shift معدل آخر. مع ذلك، لا يزال رمز المفتاح المقابل لـ F1 يُولّد عند الضغط عليه. ونتيجة لذلك، يعمل F1 كما كان من قبل (على سبيل المثال، قد تُفتح نافذة مساعدة عند الضغط عليه)، ولكنه يعمل أيضًا كمفتاح Shift (يؤدي الضغط على "a" في محرر نصوص أثناء الضغط على F1 إلى إضافة "A" إلى النص الحالي).

يحتفظ خادم X بتخطيط مُعدِّل لأزرار الماوس ويستخدمه. مع ذلك، لا يمكن سوى تبديل مواقع الأزرار . يُفيد هذا بشكل أساسي في تبديل الزر الأيسر والزر الأيمن لمستخدمي اليد اليسرى .

يعرض البرنامج xmodmapويغير تعيينات المفاتيح والمعدلات وأزرار الماوس.

الاستحواذ هو حالة يتم فيها إرسال جميع أحداث لوحة المفاتيح أو الفأرة إلى عميل واحد. يمكن للعميل طلب الاستحواذ على لوحة المفاتيح أو الفأرة أو كليهما: إذا استجاب الخادم للطلب ، تُرسل جميع أحداث لوحة المفاتيح/الفأرة إلى العميل المُستحوذ حتى يتم تحرير الاستحواذ. ولن تتلقى العملاء الآخرون هذه الأحداث.

عند طلب عملية التقاط، يُحدد العميل نافذة التقاط : تُرسل جميع الأحداث إلى العميل المُلتقط كما لو كانت مرتبطة بنافذة الالتقاط. مع ذلك، لا تتلقى العملاء الآخرون أي أحداث حتى لو قاموا بتحديدها في نافذة الالتقاط. يوجد نوعان من عمليات الالتقاط:

• نشط: تتم عملية الاستيلاء على الفور
• الوضع السلبي: لا يتم الإمساك إلا عند الضغط على مفتاح أو زر محدد مسبقًا في الماوس، وينتهي عند تحريره.

يمكن للعميل التحكم في لوحة المفاتيح أو المؤشر أو كليهما. قد يتضمن طلب التحكم طلبًا لتجميد لوحة المفاتيح أو المؤشر. الفرق بين التحكم والتجميد هو أن التحكم يُغيّر مُستقبِل الأحداث، بينما يُوقف التجميد إرسالها تمامًا. عند تجميد الجهاز، تُخزَّن الأحداث التي يُولِّدها في قائمة انتظار ليتم إرسالها كالمعتاد عند انتهاء التجميد.

بالنسبة لأحداث المؤشر، هناك معلمة إضافية تؤثر على تسليم الأحداث: قناع الحدث، الذي يحدد أنواع الأحداث التي سيتم تسليمها وتلك التي سيتم تجاهلها.

تتضمن طلبات الاستحواذ حقلاً لتحديد مصير الأحداث التي تُرسل إلى العميل المُستحوذ حتى لو لم يُنشئ عملية الاستحواذ. على وجه الخصوص، يمكن للعميل طلب إرسالها كالمعتاد أو وفقًا لعملية الاستحواذ. هذان الشرطان ليسا متطابقين كما قد يبدو. على سبيل المثال، قد يطلب عميل يستقبل عادةً أحداث لوحة المفاتيح في نافذة أولى، الاستحواذ عليها من نافذة ثانية. الأحداث التي تُرسل عادةً إلى النافذة الأولى قد تُعاد توجيهها أو لا تُعاد توجيهها إلى نافذة الاستحواذ، وذلك بناءً على المعلمة المُحددة في طلب الاستحواذ.

يمكن للعميل أيضاً طلب الاستحواذ على الخادم بأكمله. في هذه الحالة، لن يعالج الخادم أي طلبات باستثناء تلك الواردة من العميل الذي يطلب الاستحواذ.

توجد طلبات وأحداث أخرى في البروتوكول الأساسي. يتعلق النوع الأول من الطلبات بعلاقة الأصل بين النوافذ: إذ يمكن للعميل طلب تغيير النافذة الأصلية، أو طلب معلومات حول أصل النوافذ. وتتعلق طلبات أخرى بالتحديد ، الذي يخضع في الغالب لبروتوكولات أخرى. كما تتعلق طلبات أخرى بتركيز الإدخال وشكل المؤشر . ويمكن للعميل أيضًا طلب إنهاء مالك مورد (نافذة، صورة نقطية، إلخ)، مما يؤدي إلى قطع الخادم الاتصال به. وأخيرًا، يمكن للعميل إرسال طلب عدم تنفيذ أي عملية إلى الخادم.

صُمم بروتوكول X الأساسي ليكون قابلاً للتوسيع. يحدد البروتوكول الأساسي آلية للاستعلام عن الامتدادات المتاحة وكيفية إرسال طلبات الامتدادات والأحداث وحزم الأخطاء.

على وجه الخصوص، يمكن للعميل طلب قائمة بجميع الامتدادات المتاحة للبيانات المتعلقة بامتداد معين. وتتشابه حزم الامتدادات مع حزم البروتوكول الأساسي. وينص البروتوكول الأساسي على أن حزم الطلبات والأحداث والأخطاء تحتوي على عدد صحيح يشير إلى نوعها (على سبيل المثال، يُرقم طلب إنشاء نافذة جديدة بالرقم 1). ويتم حجز نطاق من هذه الأعداد الصحيحة للامتدادات.

عندما يُنشئ العميل اتصالاً مبدئياً مع الخادم، يمكن للخادم الرد إما بقبول الاتصال أو رفضه أو طلب المصادقة . يتضمن طلب المصادقة اسم طريقة المصادقة المستخدمة. لا يُحدد البروتوكول الأساسي عملية المصادقة، التي تعتمد على نوع المصادقة المستخدمة، باستثناء أنها تنتهي بإرسال الخادم إما حزمة قبول أو حزمة رفض.

أثناء التفاعل الاعتيادي بين العميل والخادم، تقتصر الطلبات المتعلقة بالمصادقة على طريقة الوصول المستندة إلى المضيف . تحديدًا، يمكن للعميل طلب تفعيل هذه الطريقة، كما يمكنه طلب قراءة وتعديل قائمة المضيفين ( العملاء ) المصرح لهم بالاتصال. لا تستخدم التطبيقات النموذجية هذه الطلبات؛ بل يستخدمها البرنامج xhostلمنح المستخدم أو البرنامج النصي صلاحية الوصول إلى قائمة الوصول إلى المضيف. تُعتبر طريقة الوصول المستندة إلى المضيف غير آمنة.

تتواصل معظم برامج العميل مع الخادم عبر مكتبة Xlib . على وجه الخصوص، تستخدم معظم برامج العميل مكتبات مثل Xaw و Motif و GTK+ و Qt ، والتي بدورها تستخدم Xlib للتفاعل مع الخادم. ويترتب على استخدام Xlib الآثار التالية:

1. يجعل Xlib العميل متزامنًا فيما يتعلق بالردود والأحداث:
   1. وظائف Xlib التي ترسل الطلبات تحظر حتى يتم استلام الردود المناسبة، إن وجدت؛ بمعنى آخر، يمكن لعميل X الذي لا يستخدم Xlib إرسال طلب إلى الخادم ثم القيام بعمليات أخرى أثناء انتظار الرد، ولكن يمكن للعميل الذي يستخدم Xlib فقط استدعاء وظيفة Xlib التي ترسل الطلب وانتظار الرد، وبالتالي حظر العميل أثناء انتظار الرد (إلا إذا بدأ العميل سلسلة رسائل جديدة قبل استدعاء الوظيفة)؛
   2. بينما يقوم الخادم بإرسال الأحداث بشكل غير متزامن ، يقوم Xlib بتخزين الأحداث التي يتلقاها العميل في قائمة انتظار ؛ ولا يمكن لبرنامج العميل الوصول إليها إلا عن طريق استدعاء وظائف مكتبة X11 بشكل صريح؛ بمعنى آخر، يُجبر العميل على الحظر أو الانتظار المشغول إذا كان يتوقع حدثًا.
2. لا يرسل Xlib الطلبات إلى الخادم فورًا، بل يخزنها في قائمة انتظار تسمى مخزن الإخراج المؤقت ؛ ويتم إرسال الطلبات الموجودة في مخزن الإخراج المؤقت فعليًا عندما:
   1. يطلب البرنامج ذلك صراحةً عن طريق استدعاء دالة مكتبة مثل XFlush؛
   2. يستدعي البرنامج دالة تعطي نتيجة تتضمن ردًا من الخادم، مثل XGetWindowAttributes؛
   3. يطلب البرنامج حدثًا في قائمة الأحداث (على سبيل المثال، عن طريق استدعاء XNextEvent) ويتم حظر الاستدعاء (على سبيل المثال، XNextEventيتم حظره إذا كانت قائمة الانتظار فارغة).

تسمح المكتبات ذات المستوى الأعلى مثل Xt (التي تستخدمها بدورها Xaw و Motif ) لبرنامج العميل بتحديد وظائف رد الاتصال المرتبطة ببعض الأحداث؛ وتتولى المكتبة مهمة استطلاع قائمة الأحداث واستدعاء الوظيفة المناسبة عند الحاجة؛ ويتم التعامل مع بعض الأحداث داخليًا بواسطة Xt، مثل تلك التي تشير إلى الحاجة إلى إعادة رسم نافذة.

توفر المكتبات ذات المستوى الأدنى، مثل XCB ، وصولاً غير متزامن إلى البروتوكول، مما يسمح بإخفاء زمن الاستجابة بشكل أفضل.

لا يفرض البروتوكول الأساسي لنظام X Window أي قيود على التواصل بين العملاء، ولا يحدد كيفية استخدام النوافذ لتكوين العناصر المرئية الشائعة في واجهات المستخدم الرسومية ( الأزرار ، القوائم ، إلخ). تُعرَّف عناصر واجهة المستخدم الرسومية بواسطة مكتبات العميل التي تُنفِّذ مجموعات أدوات واجهة المستخدم الرسومية . أما التواصل بين العملاء، فيُغطَّى بمعايير أخرى مثل مواصفات ICCCM و freedesktop . ^{[ 9 ]}

يُعدّ التواصل بين البرامج أمرًا بالغ الأهمية لعمليات التحديد، وتقسيم المخازن المؤقتة، والسحب والإفلات ، وهي الطرق التي يستخدمها المستخدم لنقل البيانات من نافذة إلى أخرى. ونظرًا لإمكانية تحكم برامج مختلفة في النوافذ، فإنّ وجود بروتوكول لتبادل هذه البيانات ضروري. كما يُعدّ التواصل بين البرامج مهمًا أيضًا لمديري نوافذ X ، وهي البرامج التي تتحكم في مظهر النوافذ والشكل العام لواجهة المستخدم الرسومية.

• بروتوكولات وبنية نظام النوافذ X
• Xlib
• الخصائص الجوهرية
• يمكن استخدام Xnee لرصد بروتوكول نظام X Window

• مؤسسة X.Org (الصفحة الرئيسية الرسمية) - نسخة طبق الأصل مع اسم النطاق 'freedesktop.org'.
• نظام X Window الداخلي ، مؤرشف بتاريخ 19 يونيو 2024 في أرشيف الإنترنت (Wayback Machine) .
• صفحات كينتون لي حول X و Motif مؤرشفة بتاريخ 20 مايو 2013 على موقع Wayback Machine
• بروتوكول نظام النوافذ X، الإصدار 11 (الإصدار الحالي)