پروتکل اصلی سیستم پنجره اکس

پروتکل اصلی سامانه پنجره‌ای اکس (به انگلیسی: X Window System core protocol) پایه‌ای‌ترین پروتکل در ساختار سامانه پنجره‌ای اکس است. سامانهٔ پنجره‌ای اکس، یک سامانه پنجره‌ای تحت شبکه برای نمایشگرهای بیت‌مپی است که برای ساختن واسط‌های گرافیکی کاربر در سیستم‌عامل‌های یونیکس، شبه یونیکس یا دیگر سیستم‌ها بکار برده می‌شود. اکس بستری را فراهم می‌کند که به‌کمک آن می‌توان نرم‌افزارهایی به همراه واسط گرافیکی (همچون میزکارهای گنوم و کی‌دی‌ئی) را بر روی این سیستم‌عامل‌ها اجرا کرده و توسعه داد. سامانهٔ پنجره‌ای اکس از یک مدل مشتری-خدمت‌گذار برخوردار است. در این مدل، یک سرویس‌دهندهٔ یگانه که سرور اکس نامیده می‌شود، همهٔ سخت‌افزارهای ورودی/خروجی همانند صفحه نمایش، صفحه کلید، ماوس و ... را کنترل می‌کند. همهٔ برنامه‌های کاربردی هم به گونهٔ سرویس‌گیرنده کار می‌کنند و با کمک سرور اکس، با کاربر یا دیگر کلاینت‌ها تعامل برقرار می‌کنند. این تعامل توسط پروتکل اصلی سامانه پنجره‌ای اکس ساماندهی می‌شود. پروتکل‌های دیگری هم در رابطه با سامانه پنجره‌ای اکس وجود دارد که این پروتکل‌ها، هم به گونهٔ یک پروتکل جدا و خودسر هستند و هم اینکه بر روی بستر پروتکل اصلی اکس ایجاد شده‌اند.
در پروتکل اصلی سامانهٔ پنجره‌ای اکس، تنها چهار گونه بسته وجود دارد که به گونهٔ ناهمگام، بر روی شبکه فرستاده می‌شود: درخواست‌ها، پاسخ‌ها، رویدادها و خطاها. درخواست‌ها از سوی کلاینت به سرور فرستاده می‌شوند تا اجرای یک کار یا دریافت اطلاعاتی را از سرور درخواست کنند. درخواست‌ها یا به سرور می‌گویند که کار خاصی را انجام دهد (همچون ایجاد کردن یک پنجره تازه) یا از سرور می‌خواهند که داده‌های دلخواهی را برای کلاینت‌ها بفرستد. پاسخ‌ها از سوی سرور برای کلاینت‌ها فرستاده می‌شوند و داده‌های درخواستی کلاینت را در خود دارند که در پاسخ به درخواست کلاینت‌ها برای آن‌ها فرستاده می‌شود. رویدادها از سوی سرور برای کلاینت فرستاده می‌شوند و کلاینت را از کارهایی که کاربر سرگرم انجام‌دادن آنهاست یا رخدادهای دیگری که ممکن است کلاینت علاقه‌مند به دانستن آن‌ها باشد، باخبر می‌کنند و کلاینت می‌تواند واکنش درخور به آن رویدادها را نشان دهد. هنگامی که رویداد غیرمنتظره‌ای در هنگام پردازش کردن درخواست‌های کلاینت رخ می‌دهد و خطایی روی می‌دهد، سرور این خطاها را به کمک بسته‌هایی از نوع خطا به آگاهی کلاینت می‌رساند. درخواست‌ها ممکن است باعث تولید کردن پاسخ‌ها، رویدادها یا خطاها شوند؛ افزون بر آن، سرور اجبار نمی‌کند که بسته‌ها حتماً باید به ترتیب خاصی بر روی شبکه ارسال شوند. چندین افزونه برای پروتکل اصلی هست که هر کدام درخواست‌ها، پاسخ‌ها، رویدادها و خطاهای ویژهٔ خودشان را دارند.
اکس در سال ۱۹۸۴ و از مؤسسه فناوری ماساچوست سرچشمه گرفته‌است. نسخهٔ کنونی آن که X11 نام دارد، در سپتامبر ۱۹۸۷ ساخته شده‌است. اینکه سامانه پنجره‌ای اکس «مکانیسم و سازوکار را مشخص می‌کند، نه خط مشی را»، اصل اولیه‌ای بود که طراحان سیستم، باب شیفلر و جیم گتیز، آن را گزیدند. در نتیجه، پروتکل اصلی، چگونگی تعامل بین کلاینت‌ها یا تعامل بین یک کلاینت با یک کاربر را تعیین نمی‌کند. چگونگی انجام این تعامل‌ها در مشخصه‌های فنی دیگری بحث می‌شوند، همانند ICCCM و freedesktop.org و عموماً هنگامی که برنامه‌نویس تصمیم به استفاده از یک ابزار ویجت می‌گیرد، چگونگی انجام این تعامل و خصوصیات هم خودکار اعمال می‌شوند.

پنجره‌ها

چیزی که در بسیاری از واسط‌های گرافیکی کاربر پنجره نامیده می‌شود، در سامانهٔ پنجره‌ای اکس به آن پنجره سطح بالا می‌گویند. همچنین اصطلاح پنجره برای نامیدن پنجره‌هایی که در درون یک پنجره دیگر جای دارند هم بکار می‌رود. به پنجره‌ای که یک پنجره دیگر را دربرمی‌گیرد، پنجره پدر و به پنجره‌ای که درون یک پنجره دیگر جای گرفته زیرپنجره گفته می‌شود. عناصر گرافیکی همچون دکمه‌ها، منوها، آیکون‌ها و دیگر چیزها، می‌توانند بدست زیرپنجره‌ها محقق شوند.
کلاینت می‌تواند از سرور درخواست کند که یک پنجره تازه ساخته شود. همچنین کلاینت می‌تواند درخواست کند که یک زیرپنجره در درون پنجره‌ای که از پیش وجود دارد، ساخته شود. در نتیحه، پنجره‌هایی که بدست کلاینت‌ها ساخته می‌شوند، در یک ساختار درختی و به گونهٔ سلسله‌مراتبی، چیده می‌شوند. ریشهٔ این درخت، پنجره ریشه است. پنجره ریشه یک پنجرهٔ ویژه است و در هنگام آغاز به کار سیستم به گونه خودکار بدست سرور ساخته می‌شود. همه پنجره‌های دیگر به گونه مستقیم یا غیرمستقیم فرزند پنجره ریشه هستند. پنجره‌های سطح بالا، فرزند مستقیم پنجره ریشه شمرده می‌شوند. از دید ظاهری، پنجره ریشه به بزرگی یک دسکتاپ مجازی است و در پشت همه پنجره‌های دیگر نهفته می‌شود.
تضمینی برای نگهداری همیشگی محتویات و درون‌مایهٔ یک پنجره در کار نیست. درون‌مایهٔ یک پنجره می‌تواند با جابجا شدن پنجره، تغییر اندازه دادن پنجره، گذاشتن پنجره‌های دیگر بر روی آن پنجره، یا ... نابود شده و همه یا بخشی از آن نمایش‌ناپذیر شود. اگر سرور یک انباره پشتیبان از درون‌مایهٔ یک پنجره را نگه نداشته باشد، درون‌مایهٔ یک پنجره ممکن است از دست برود. کلاینت می‌تواند از سرور بخواهد که چنین انباره‌ای را از درون‌مایهٔ یک پنجره نگه‌داری کند، اما سرور تعهد و ضمانتی برای انجام این کار ندارد. در نتیجه، کلاینت‌ها نمی‌توانند چنین بپندارند که سرور یک انباره پشتیبان برای یک پنجره را نگه‌داری می‌کند. اگر بخش نمایان یک پنجره، درون‌مایهٔ نامشخصی داشته باشد، رویدادی برای کلاینت فرستاده می‌شود و او را آگاه می‌کند که درون‌مایهٔ پنجره باید دوباره ترسیم شوند.
هر پنجره‌ای تعدادی صفت دارد. همانند ژئومتری (اندازه پنجره و جای آن بر روی صفحه)، تصویر پس‌زمینه آن، اینکه آیا انباره پشتیبان برای آن نگهداری می‌شود یا نه و صفت‌های دیگر. تعدادی درخواست برای بررسی کردن این صفت‌ها و تغییر دادن آن‌ها در پروتکل تعبیه شده‌است.
پنجره‌ها می‌توانند به گونه InputOutput (هم ورودی داشته باشند و هم خروجی) یا به گونه InputOnly (تنها ورودی) باشند. پنجره‌های InputOutput می‌توانند بر روی صفحه نمایش داده شوند و برای ترسیم کردن بکار برده می‌شوند. پنجره‌های InputOnly هیچگاه بر روی صفحه نمایش نمی‌یابند و آن‌ها تنها برای دریافت ورودی از کاربر بکاربرده می‌شوند.
قاب زینتی و نوار عنوان پنجره‌ها (که می‌تواند شامل شماری دکمه هم باشد) که گرداگرد پنجره‌ها دیده می‌شود، بدست برنامه‌ای ویژه به نام مدیر پنجره رسم می‌شود، نه بدست کلاینتی که پنجره را ساخته و صاحب آن است. همچنین این مدیر پنجره است که مسئول سرپرستی کردن ورودی مرتبط با این عناصر است. برای نمونه، هنگامی که کاربر با نشانگر ماوس بر روی قاب پنجره کلیک می‌کند و آن را تغییر اندازه می‌دهد، در واقع این مدیر پنجره است که پنجره را کوچک و بزرگ می‌کند و آن را تغییر اندازه می‌دهد. کلاینت‌ها معمولاً بدون توجه و در نظر گرفتن تغییرات انجام شده بدست مدیر پنجره، بر روی پنجره‌هایی که ساخته‌اند به فعالیت می‌پردازند. مدیر پنجره‌های ری-پرنتینگ پس از ساختن یک پنجره سطح بالا، پدر این پنجره تازه‌ایجادشده را به پنجره‌ای جز پنجرهٔ ریشه، که برای همین منظور در نظر گرفته شده، تغییر می‌دهند. تقریباً همه مدیر پنجره‌های نوین، ری-پرنتینگ هستند. از دید پروتکل، مدیر پنجره هم تنها یک کلاینت است و با کلاینت‌های دیگر فرقی ندارد.
اطلاعات مربوط به یک پنجره را می‌توان با برنامه xwininfo بدست آورد. با فرستادن آرگومان خط فرمانی ‎-tree به این برنامه، می‌توان درخت زیرپنجره‌های یک پنجره را به همراه شناسه‌ها و داده‌های ژئومتری آن پنجره‌ها دید.

پیکس‌مپ و ترسیم‌پذیرها

یک پیکس‌مپ بخشی از حافظه است که می‌توان آن را برای ترسیم کردن بکار برد. برخلاف پنجره‌ها، پیکس‌مپ‌ها به گونه خودکار بر روی صفحه، نمایش نمی‌یابند. با این حال، محتوای یک پیکس‌مپ (یا بخشی از آن) می‌تواند به یک پنجره منتقل شود (یا برعکس، محتوای یک پنجره به یک پیکس‌مپ برده شود). به کمک این کار، می‌توان شگردهایی همچون بافرینگ دوگانه را به اجرا درآورد. بسیاری از عملیات‌های گرافیکی که بر روی پنجره‌ها می‌توان انجام داد، بر روی پیکس‌مپ‌ها هم انجام‌پذیر است.
پنجره‌ها و پیکس‌مپ‌ها روی هم ترسیم‌پذیر نامیده می‌شوند و محتوای آن‌ها در سرور جای داده می‌شود. با این حال، یک کلاینت می‌تواند درخواست کند که محتوای یک ترسیم‌پذیر از سرور به کلاینت یا از کلاینت به سرور جابجا شود.

بافت‌های گرافیکی و فونت‌ها

کلاینت می‌تواند شماری عملیات گرافیکی همچون پاک‌سازی یک بخش، کپی کردن درون‌مایهٔ یک بخش به بخشی دیگر، رسم کردن نقطه، خط، مستطیل، متن و... را از سرور درخواست کند. افزون بر پاک کردن، همه این عملیات‌ها بر روی همه ترسیم‌پذیرها (پنجره و پیکس‌مپ) هم انجام‌پذیر است.
بیشتر درخواست‌هایی که کلاینت برای انجام عملیات‌های گرافیکی به سرور می‌فرستد، یک بافت گرافیکی در خود دارند. بافت گرافیکی ساختاری است که دربرگیرنده پارامترهایی برای عملیات‌های گرافیکی است. یک بافت گرافیکی رنگ پیش‌زمینه، رنگ پس‌زمینه، فونت متن و دیگر پارامترهای گرافیکی را در خود دارد. در هنگام درخواست دادن یک عملیات گرافیکی، کلاینت یک بافت گرافیکی را هم به همراه درخواست خود برای سرور می‌فرستد. همه پارامترهای بافت گرافیکی بر روی همه عملیات‌ها تأثیرگذار نیستند. برای نمونه، فونت یک متن، تأثیری بر روی رسم کردن یک خط ندارد.
پروتکل، چگونگی بکاربردن فونت‌های سمت سرور را هم تعریف و مشخص می‌کند. چنین فونت‌هایی به گونه فایل ذخیره می‌شوند و سرور به آن‌ها یا به صورت مستقیم و با سیستم فایل دسترسی دارد یا به آن‌ها به گونه غیرمستقیم و با شبکه و برنامه‌ای که سرویس‌دهنده فونت نامیده می‌شود، دسترسی دارد. کلاینت‌ها می‌توانند فهرست همه فونت‌های موجود را از سرور درخواست کنند و پس از اینکه فونتی را از فهرست برگزیدند، می‌توانند از سرور بخواهند که آن فونت را بارگذاری کند (اگر هنوز بارگذاری نشده باشد) یا آن فونت را باراندازی کند (اگر کلاینت‌های دیگر سرگرم استفاده از آن نباشند). یک کلاینت می‌تواند اطلاعات کلی دربارهٔ یک فونت و همچنین مقدار فضایی که یک رشته متنی خاص در هنگام رسم شدن با آن فونت نیاز دارد را از سرور درخواست کند. در سطح پروتکل، نام فونت‌ها می‌تواند رشته‌های دلخواهی باشد. در قرارداد توصیف منطقی فونت‌های اکس چگونگی نام‌گذاری فونت‌ها بر اساس خصوتیاتشان مشخص شده‌است. این قرارداد همچنین مقادیر دلخواهی که می‌توانند به فونت‌ها چسبیده شوند را هم مشخص می‌کنند.
برنامه xlsfonts فهرست فونت‌هایی که در سرور ذخیره شده‌اند را چاپ می‌کند.
هم‌اکنون، با وجود فونت‌های سمت کلاینت، فونت‌های سمت سرور منسوخ شده‌اند. فونت‌های سمت کلاینت بدست خود کلاینت رندر می‌شوند و سرور آن‌ها را رندر نمی‌کند. کتابخانه اکس‌اف‌تی، کایرو و افزونه اکس‌رندر چنین پشتیبانی را فراهم می‌کنند. مشخصات این فونت‌ها در پروتکل اصلی تعریف و مشخص نشده‌است.

رویدادها

رویدادها، بسته‌هایی هستند که از سوی سرور برای کلاینت فرستاده می‌شوند، این بسته‌ها کلاینت را از رخ دادن رویدادی که ممکن است برای کلاینت جالب توجه باشد، آگاه می‌کنند. برای نمونه، هنگامی که کاربر کلیدی را فشار می‌دهد یا بر روی دکمه‌ای کلیک می‌کند، رویدادی برای کلاینت فرستاده می‌شود. رویدادها تنها برای ورودی گرفتن از کاربر و فعل و انفعالات او نیستند. برای نمونه، هنگامی که زیرپنجره‌ای در یک پنجره ساخته می‌شود، رویدادی برای آگاه کردن کلاینت از این رخداد، برای آن فرستاده می‌شود.
هر رویدادی با یک پنجره در ارتباط است. برای نمونه، اگر کاربر هنگامی که نشانگر ماوس بر روی یک پنجره قرار دارد، روی آن پنجره کلیک کند، رویداد با آن پنجره در ارتباط خواهد بود. بستهٔ رویدادی که برای کلاینت فرستاده می‌شود، شناسه آن پنجره را در بر دارد.
یک کلاینت می‌تواند از سرور بخواهد که رویدادی را برای یک کلاینت دیگر بفرستد؛ کلاینت‌ها از این ویژگی برای برقراری ارتباط با یکدیگر استفاده می‌کنند. برای نمونه، هنگامی که کلاینتی از سرور درخواست می‌کند که متن انتخاب‌شده بدست کاربر برایش فرستاده شود، یک چنین رویدادی ساخته می‌شود (ممکن است کاربر متن موجود در پنجره‌ای که متعلق به یک کلاینت دیگر است را انتخاب کرده باشد)؛ این رویداد، برای کلاینتی فرستاده می‌شود که پنجره حاوی متن انتخاب‌شده را اداره می‌کند.
هنگامی که محتویات بخشی از یک پنجره، نابود شده و سپس دوباره نمایان می‌شود، رویدادی به نام Expose برای کلاینت فرستاده می‌شود. محتوای یک پنجره می‌تواند در برخی شرایط نابود شود. برای نمونه اگر یک پنجره، بر روی پنجره دیگری جای بگیرد و همه یا بخشی از آن را بپوشاند، محتوای پنجره پوشیده شده نابود خواهد شد. البته این هنگامی است که سرور انباره پشتیبان برای آن پنجره را نگه‌داری نکرده باشد. سرور تضمین نمی‌کند که حتماً یک انباره پشتیبان نگه‌داری می‌کند، اما تضمین می‌کند که هر گاه نیاز به ترسیم دوباره محتوای یک پنجره بود، رویدادی را برای کلاینت بفرستد.
بسیاری از رویدادها تنها هنگامی برای کلاینت فرستاده می‌شوند که کلاینت از پیش آمادگی خود را برای دریافت آن‌ها اعلام کرده باشد و مایل به دریافت آن رویدادها بوده باشد. دلیل این کار این است که شاید تنها چند گونه رویداد خاص برای برخی از کلاینت‌ها جالب توجه باشد و کلاینت‌ها نخواهند به همه آن‌ها پاسخ دهند. برای نمونه، یک کلاینت ممکن است تنها بخواهد از رویدادهای صفحه‌کلید آگاه شود و علاقه‌ای به رویدادهای ماوس نداشته باشد. با این حال، رویدادهایی هستند که حتی اگر کلاینت از پیش آمادگی خود را برای دریافت آن‌ها نشان نداده باشد، باز هم برای کلاینت فرستاده می‌شوند.
کلاینت‌ها با تنظیم کردن یکی از خصوصیات پنجره، مشخص می‌کنند که علاقه‌مند به دریافت کردن چه رویدادهایی هستند. برای نمونه، برای ترسیم دوباره پنجره‌ای که محتوای آن نابود شده، کلاینت باید رویداد Expose را دریافت و پذیرش کند (این رویداد برای همین کار در نظر گرفته شده و  کلاینت را آگاه می‌کند که محتوای پنجره نیازمند ترسیم دوباره است). با این حال، این رویداد تنها هنگامی برای کلاینت فرستاده می‌شود که کلاینت از پیش اعلام کرده باشد که می‌خواهد آن را دریافت کند. این کار با تنظیم کردن خصوصیت ماسک رویداد پنجره، با یک مقدار مناسب انجام می‌شود.
کلاینت‌های گوناگون می‌توانند رویدادهای مرتبط با یک پنجره یکسان را دریافت کنند. آن‌ها حتی می‌توانند ماسک رویداد آن پنجره را به گونهٔ متفاوتی مقداردهی کنند و بدین گونه، هر کدام رویدادهای گوناگونی را دریافت کنند. برای نمونه، یک کلاینت شاید بخواهد تنها رویدادهای مرتبط با صفحه‌کلیدی که برای یک پنجره رخ می‌دهد را دریافت کند، در حالی که کلاینت دیگر دوست دارد تنها رویدادهای مرتبط با ماوس برای همان پنجره را دریافت کند. این کار برای این شدنی است که سرور برای هر پنجره، ماسک رویداد جداگانه‌ای را به ازای هر کلاینت نگه‌داری می‌کند. با این حال، برخی از رویدادها تنها می‌توانند در هر زمان بدست یک کلاینت دریافت شوند و کلاینت‌های دیگر نمی‌توانند همزمان همان رویداد را دریافت کنند. این رویدادها، گزارش‌هایی را دربارهٔ کلیک کردن دکمه‌های ماوس و همچنین تغییرات مرتبط با مدیریت پنجره را می‌فرستند.
برنامه xev رویدادهای مرتبط با یک پنجره را نمایش می‌دهد. دستور xev -id WID همه رویدادهای ممکن برای پنجره‌ای با شناسه WID را دریافت کرده و چاپ می‌کند.

اتم‌ها

اتم‌ها اعداد ۳۲ بیتی هستند که رشته‌ها را نمایش می‌دهند. سازندگان پروتکل، اتم‌ها را به این دلیل معرفی کردند، که اتم‌ها رشته‌ها را به شکلی کوتاه و با اندازه‌ای ثابت نمایش می‌دهند. در حالی که یک رشته می‌تواند طول دلخواهی داشته باشد، یک اتم همیشه اندازه ثابت ۳۲ بیتی دارد. در مواردی که بسته‌هایی با یک رشته یکسان باید به صورت چند باره فرستاده شود، می‌توان با اتم‌ها، از شبکه به گونه بهینه‌تر سود جست. بسته‌های نوع رویداد که اندازه ثابت ۳۲ بایتی دارند، می‌توانند اتم‌ها را در خود جای دهند، اما ممکن است یک رشته متنی به اندازه‌ای بزرگ باشد که نتوان آن را در بسته‌های رویداد گنجاند.
به گونه دقیقتر می‌توان گفت که اتم‌ها، شناسه‌هایی برای رشته‌هایی که در سرور ذخیره شده‌اند، هستند. آن‌ها همانند شناسه‌های منابع (پنجره، پیکس‌مپ و غیره) هستند. اما دو تفاوت با آن‌ها دارند. یکی اینکه شناسه اتم‌ها بدست سرور گزیده می‌شود و کلاینت در گزینش آن‌ها نقشی ندارد. به عبارتی دیگر، هنگامی که کلاینت درخواست ساختن یک اتم تازه را می‌دهد، تنها رشته‌ای که قرار است ذخیره شود را برای سرور می‌فرستد، نه شناسه آن اتم را. این شناسه را سرور گزینش کرده و به صورت یک پاسخ برای کلاینت می‌فرستد. دومین فرق مهم بین اتم‌ها و منابع این است که اتم‌ها با کلاینت‌ها در ارتباط نیستند و به آن‌ها وابسته نیستند. هنگامی که اتم‌ها در سرور ساخته می‌شوند، تا هنگامی که سرور خاموش یا راه‌اندازی دوباره نشده، در همان‌جا باقی خواهند ماند (منابع به گونه پیشفرض چنین رفتاری ندارند و وابسته به کلاینت هستند).
از آنجا که اتم‌ها یک نوع شناسه هستند، یکتا هم هستند. با این حال، یک اتم و شناسه یک منبع می‌توانند با یکدیگر همپوشانی داشته باشند. رشته‌ای که به یک اتم داده شده، نام اتم نامیده می‌شود. پس از اینکه یک اتم ساخته شد، نام آن را نمی‌توان تغییر داد و دو اتم هم نمی‌توانند نام یکسانی داشته باشند. در نتیجه، معمولاً از نام یک اتم برای اشاره به آن اتم استفاده می‌شود. «اتم ABCD» به شکل دقیقتر یعنی «اتمی که رشته ABCD به آن اختصاص یافته است». یک کلاینت، هم می‌تواند از سرور درخواست کند که یک اتم تازه بسازد و هم می‌تواند با دادن یک رشته به سرور، شناسه اتم آن را دریافت کند. برخی از اتم‌ها از قبل تعریف شده هستند. (سرور آن‌ها را با یک شناسه و رشته معین از قبل تعریف کرده‌است).
اتم‌ها را می‌توان برای اهداف گوناگونی بکار برد. یکی از رایج‌ترین استفاده از اتم‌ها، برقرار کردن ارتباط بین دو یا چند کلاینت است که همگی به یک سرور یکسان متصل شده‌اند. آن‌ها به همراه ویژگی‌های پنجره‌ها استفاده می‌شوند که در ادامه تشریح می‌شود.
با استفاده از برنامه xlsatoms می‌توان فهرست همه اتم‌های موجود در سرور را چاپ کرد. این برنامه برای هر اتم، شناسه آن (که یک عدد است) و نام آن (که یک رشته است) را چاپ می‌کند.

خصیصه‌ها

هر پنجره، یک سری ویژگی از پیش تعریف شده و یک سری خصیصه دارد که همه آن‌ها در سرور ذخیره می‌شوند و کلاینت می‌تواند برای دسترسی به آنها، درخواستی را برای سرور بفرستد. ویژگی‌ها، اطلاعاتی دربارهٔ یک پنجره هستند، مانند اندازه، مکان، رنگ پس‌زمینه و دیگر جیزها. خصیصه‌ها، اطلاعات دلخواهی هستند که به یک پنجره چسبیده می‌شوند. برخلاف ویژگی‌ها، خصیصه‌ها معنی خاصی در سطح پروتکل اکس ندارند. یک کلاینت می‌تواند هر گونه اطلاعات دلخواهی را در خصیصه یک پنجره ذخیره کند.
یک خصیصه با نام، نوع و مقدار آن شناخته می‌شود. خصیصه‌ها همانند متغیرها در زبان‌های برنامه‌نویسی دستوری هستند، که یک کلاینت می‌تواند خصیصه تازه‌ای را با نام و نوع دلخواه ساخته و مقداری را در آن بگذارد. خصیصه‌ها مخصوص همان پنجره هستند: دو خصیصه همنام می‌تواند در دو پنجره گوناگون وجود داشته باشد، در حالی که مقدار و نوع آن‌ها با یکدیگر ناهمسان است.
نام، نوع و مقدار یک خصیصه به صورت رشته، یا به شکل دقیق‌تر، اتم هستند. رشته‌ها در سرور ذخیره شده و کلاینت می‌تواند با شناسه‌ها به آن‌ها دسترسی داشته باشد. یک کلاینت می‌تواند با شناسهٔ اتمی که دربرگیرنده نام یک خصیصه است، به آن خصیصه دسترسی داشته باشد.
خصیصه‌ها بیشتر برای ارتباطات بین کلاینتی بکار برده می‌شوند. برای نمونه، یک خصیصه به نام WM_NAME (این خصیصه توسط اتمی که رشته اختصاص یافته به آن "WM_NAME" است نامگذاری شده‌است) هست که برای ذخیره کردن نام پنجره‌ها بکار برده می‌شود. مدیر پنجره‌ها معمولاً این خصیصه را می‌خوانند و سپس آن را در نوار عنوان پنجره نمایش می‌دهند.
برخی از انواع ارتباطات بین کلاینتی، از خصیصه‌های پنجره ریشه استفاده می‌کنند. برای نمونه، بر پایه مشخصاتی که فری‌دسکتاپ برای مدیر پنجره‌ها تعریف کرده، مدیر پنجره‌ها باید شناسه پنجره‌ای که هم‌اکنون فعال است و فوکوس را در اختیار دارد را در یکی از خصیصه‌های پنجره ریشه به نام ‎_NET_ACTIVE_WINDOW ذخیره کنند. منابع اکس که حاوی پارامترهای برنامه‌ها هستند هم در خصیصه‌های پنجره ریشه ذخیره می‌شوند. به این گونه، همه کلاینت‌ها می‌توانند به این خصیصه‌ها دسترسی داشته باشند، حتی اگر این کلاینت‌ها بر روی رایانه‌های گوناگون اجرا شوند.
برنامه xprop خصیصه‌های یک پنجره دلخواه را نمایش می‌دهد. دستور xprop -root، نام، نوع و مقدار همه خصیصه‌های پنجره ریشه را چاپ می‌کند.

دیگر موارد

رویدادها و درخواست‌های دیگری هم در پروتکل وجود دارد. برخی از درخواست‌ها، در مورد رابطهٔ پدری بین پنجره‌ها هستند. یک کلاینت می‌تواند درخواست کند تا پدر یک پنجره تغییر یابد. یا می‌تواند اطلاعاتی را در مورد پدر یک پنجره درخواست کند. برخی دیگر از درخواست‌ها، دربارهٔ انتخاب‌ها هستند، با این حال، بیشتر این درخواست‌ها بدست پروتکل‌های دیگری جز پروتکل اصلی تعریف و مشخص می‌شوند. دسته دیگر از درخواست‌ها، درخواست‌های مرتبط با فوکوس ورودی و شکل مکان‌نما هستند. همچنین یک کلاینت می‌تواند درخواست دهد مالک یک منبع (پنجره، pixmap و ...)، از بین برود که خود باعث از بین رفتن ارتباط سرور با آن می‌شود. در نهایت، یک کلاینت می‌تواند یک درخواست از نوع بدون عملیات را برای سرور بفرستد.

اضافات و افزونه‌ها

پروتکل سامانه پنجره‌ای اکس به گونه گسترش‌پذیر ساخته شده‌است. این پروتکل سازوکاری را فراهم می‌کند که یک کلاینت به کمک آن می‌تواند از وجود داشتن یک افزونه مطمئن شود. همچنین پروتکل اصلی، چگونگی ساخته شدن بسته‌های درخواست، رویداد و خطایی که متعلق به یک افزونه هستند را هم مشخص می‌کند.
یک کلاینت می‌تواند برای داده‌هایی که وابسته و مرتبط به یک افزونه دلخواه هستند، فهرست همه افزونه‌های موجود را درخواست کند. بسته‌هایی که متعلق به یک افزونه هستند، مشابه همان بسته‌های اصلی پروتکل هستند. پروتکل اصلی، مشخص می‌کند که بسته‌های نوع درخواست، رویداد یا خطا، باید دربرگیرنده یک عدد صحیح باشند که این عدد صحیح، نوع آن بسته را مشخص می‌کند (برای نمونه، درخواست‌هایی که برای ساختن یک پنجره تازه بکار می‌روند، با عدد ۱ شماره‌گذاری می‌شوند). بازه‌ای از این اعداد صحیح برای افزونه‌ها رزرو شده‌است.

اعتبارسنجی و تأیید هویت

در ابتدا، وقتی که کلاینت می‌خواهد ارتباطی را با سرور برقرار کند، سرور می‌تواند ارتباط را بپذیرد، آن را رد کند، یا کلاینت را اعتبارسنجی کند و در صورت تأیید شدن هویت کلاینت، ارتباط با آن را بپذیرد. روش‌های گوناگونی برای اعتبارسنجی هست. یک درخواست اعتبارسنجی، روشی که باید برای اعتبارسنجی بکار برده شود را در خود دارد. پروتکل، مراحل انجام اعتبارسنجی را مشخص و تعریف نمی‌کند، چرا که مراحل اعتبارسنجی بستگی به روشی دارد که برای اعتبارسنجی بکار برده می‌شود، پروتکل تنها مشخص می‌کند که این فرایند، یا با فرستادن بسته پذیرش یا با فرستادن بسته عدم پذیرش از سوی سرور، پایان می‌یابد.
در طول یک فعل و انفعال عادی بین یک کلاینت و سرور، تنها درخواست‌هایی که با اعتبارسنجی در ارتباط هستند، در مورد روش دسترسی مبتنی بر میزبان هستند. به‌طور دقیق‌تر، یک کلاینت می‌تواند از سرور بخواهد که این روش فعال باشد یا نه، و همین‌طور می‌تواند از سرور بخواهد که فهرستی از میزبان‌هایی (کلاینت‌هایی) که مجاز به برقراری ارتباط هستند را بخواند یا تغییر دهد. برنامه‌های عادی از این‌گونه درخواست‌ها استفاده نمی‌کنند، این درخواست‌ها توسط برنامه xhost استفاده می‌شوند. این برنامه از این درخواست‌ها به این منظور استفاده می‌کند تا به یک کاربر یا یک اسکریپت، اجازه دسترسی داشتن به سرور اکس را بدهد.

بخش‌های تشریح‌نشده

پروتکل اصلی سامانه پنجره‌ای اکس در مورد ارتباطات بین کلاینتی حکم نمی‌کند و مشخص نمی‌کند که برای ساختن عناصر دیداری رایج در واسط‌های گرافیکی کاربر (دکمه‌ها، منوها و ...)، چگونه باید پنجره‌ها را بکار برد. این عناصر با کتابخانه‌های سمت کلاینت مشخص و تعریف می‌شوند. ارتباطات بین کلاینتی در استانداردهای دیگری مانند ICCCM و مشخصه‌های freedesktop پوشش داده می‌شود.
ارتباطات بین کلاینتی با سلکشن‌ها، کات بافرها، و عمل drag-and-drop انجام می‌شود. این موارد، روش‌هایی هستند که یک کاربر می‌تواند آن‌ها را برای جابجا کردن داده‌ها از یک کلاینت به کلاینت دیگر بکار برد. از آنجا که پنجره‌ها ممکن است بدست برنامه‌های گوناگونی کنترل شوند، پروتکلی برای جابجایی این داده‌ها نیاز هست تا هماهنگی و ارتباط بین برنامه‌ها ساماندهی. ارتباطات بین کلاینتی همچنین با مدیر پنجره‌های اکس هم در ارتباط است. مدیر پنجره‌ها برنامه‌هایی هستند که ظاهر پنجره‌ها و نما و حس کلی رابط کاربری را کنترل می‌کنند. مبحث مرتبط دیگر در ارتباطات بین کلاینتی، مبحث مدیریت جلسه یا مدیریت نشست است.
چگونگی آغاز یک نشست کاربری، مسئله دیگری است که در پروتکل اصلی در مورد آن بحث نشده‌است. عموماً این کار به گونه خودکار بدست مدیر نشست اکس اداره می‌شود. با این حال کاربر می‌تواند به گونه دستی هم نشستی را با اجرا کردن برنامه‌های startx و xinit آغاز نماید.

انتقادها

معماری اکس به‌گونه‌ای است که کلاینت و سرور دو موجودیت جداگانه هستند که با شبکه با هم ارتباط برقرار می‌کنند، حتی اگر هر دو بر روی یک رایانه یکتا اجرا شوند. اطلاعات باید در یک سو بسته‌بندی شده، بر روی کانال مخابراتی فرستاده و سپس در سوی دیگر، از حالت بسته‌بندی بیرون آورده شود. این کار سربار اضافه‌ای بر روی سیستم تحمیل می‌کند.
به گونه پیش‌فرض، کلیه اطلاعات به‌صورت رمزنگاری‌نشده بر روی شبکه جابجا می‌شوند که یک مهاجم می‌تواند با شنود کردن کانال مخابره‌ای بین سرور و کلاینت، اطلاعات را کشف و ضبط کند. یک راه حل رایج برای حل این مشکل، برقرار کردن یک تونل پوسته امن بین کلاینت و سرور است.
پروتکل اکس به گونه ناهمگام طراحی شده‌است که این مسئله می‌تواند در برخی موارد منجر به به وجود آمدن شرایط رقابتی در بخش‌های گوناگون سیستم شود.
نداشتن رهنمود در مورد چگونگی طراحی رابط کاربری باعث به وجود آمدن رابط‌های ناسازگار شده‌است. اکس به خاطر طراحی پیچیده آن مورد انتقاد قرار گرفته‌است و همچنین برنامه‌های کاربردی ناچار هستند تا با پیچیدگی‌های سطح پایین سخت‌افزاری سروکار داشته باشند.