stanford-oval/wikipedia huggingface dataset:
جغرافیای کوئینزلند
مناطق حفاظت شده

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

منطقه مسکونی در England
| Penistone | Penistone |
| --- | --- |
 Market Street, Penistone:  Market Street, Penistone
جمعیت: ۱۰٬۱۰۱ (2001)
مرجع شبکه OS: SE245033 
• لندن: ۱۵۵ مایل (۲۴۹ کیلومتر) SSE
محله مدنی: Penistone
کلان‌شهر مستقل: Barnsley
Metropolitan county: یورک‌شر جنوبی
ناحیه: یورک‌شر و هامبر
کشور: England
کشور مستقل: بریتانیا
پست شهر: SHEFFIELD
کدپستی منطقه: S36
کد تلفن: 01226
پلیس: South Yorkshire
آتشنشانی: South Yorkshire
آمبولانس: Yorkshire
 :  
مجلس انگلستان: Penistone and Stocksbridge
 فهرست مکان‌‌ها بریتانیا انگلستان Yorkshire :  فهرست مکان‌‌ها بریتانیا انگلستان Yorkshire 
latitudeپنیستونlongitudeپنیستون
پنیستون (به انگلیسی: Penistone) یک شهرک در بریتانیا است که در انگلستان واقع شده‌است.
خصوصیات

پنیستون ۱۰٬۱۰۱ نفر جمعیت دارد.
پراهمیت‌ترین بیت

در محاسبات کامپیوتری مهم‌ترین بیت به بیتی گفته می‌شود که در عدد باینری بالاترین ارزش را دارد.
به MSB سمت چپ‌ترین بیت هم گفته می‌شود که به دلیل نوشتن اعداد با ارزش بالاتر در از سمت چپ در نشان گذاری مرتبه‌ای می یاشد.
MSB می‌تواند مربوط به بیت علامت عدد باینری علامت دار در نشانه گذاری مکمل یک یا مکمل دو باشد. در اینصورت عدد ۱ به معنای منفی و عدد ۰ نشانگر عدد مثبت می‌باشد.
به‌طور معمول به هرکدام از بیت‌ها یک عدد بر حسب موقعیت مکانی اختصاص داده می‌شود. در این حالت از صفر تا N-1 به صورتی که N نمایانگر تعداد بیت‌های مورد نیاز برای نمایش عدد در سیستم باینری می یاشد. این اعداد توان ارزش مکانی بیت مربوطه در سیستم مبنای دو است (به عنوان مثال 20..231). با وجود اینکه چندین تولیدکننده پردازنده شماره بیت را به صورت کاملاً برعکس انجام می‌دهند اما MSB همچنان با مهم‌ترین بیت باقی مانده. شاید این یکی از دلایلی باشد که از MSB به جای شماره بیت استفاده می‌شود هرچند که دلیل اصلی احتمالاً این مسئله است که سیستم‌های مختلف نمایش اعداد از تعداد بیت‌های مختلف استفاده می‌کنند.
با بسط این موضوع مهم‌ترین بیت‌ها بیت‌هایی هستند که به MSB نزدیکترند.
The unsigned binary representation of decimal 149, with the msb highlighted.  The msb in an 8-bit binary number represents a value of 128 decimal.  The lsb represents a value of 1.
شهرستان فریبلت، مینه‌سوتا

| Faribault County | Faribault County |
| --- | --- |
شهرستان: شهرستان
Faribault County Courthouse in بلو ارث، مینه‌سوتا, Minnesota: Faribault County Courthouse in بلو ارث، مینه‌سوتا, Minnesota
موقعیت درون ایالت مینه‌سوتا، ایالات متحده: موقعیت درون ایالت مینه‌سوتا، ایالات متحده
موقعیت مینه‌سوتا در ایالات متحده: موقعیت مینه‌سوتا در ایالات متحده
مختصات: ۴۳°۴۱′شمالی ۹۳°۵۷′غربی﻿ / ﻿۴۳٫۶۸°شمالی ۹۳٫۹۵°غربی﻿ / 43.68; -93.95: مختصات: ۴۳°۴۱′شمالی ۹۳°۵۷′غربی﻿ / ﻿۴۳٫۶۸°شمالی ۹۳٫۹۵°غربی﻿ / 43.68; -93.95
کشور:  ایالات متحده آمریکا
ایالت:  مینه‌سوتا
پایه‌گذاری: February 20 ۱۸۵۵
همنام: Jean Baptiste Faribault, a trader with the  Dakota .
مرکز: Blue Earth
بزرگ‌ترین شهر: Blue Earth
مساحت: مساحت
 • کل: ۷۲۱٫۶۱ مایل مربع (۱۸۶۹٫۰ کیلومتر مربع)
 • خشکی: ۷۱۳٫۶۳ مایل مربع (۱۸۴۸٫۳ کیلومتر مربع)
 • آب: ۷٫۹۸ مایل مربع (۲۰٫۷ کیلومتر مربع)  ۱٫۱۱%
جمعیت (۲۰۱۰): جمعیت (۲۰۱۰)
 • کل: ۱۴۵۵۳
 • تراکم: ۲۳/مایل مربع (۹/کیلومتر مربع)
منطقهٔ زمانی: یوتی‌سی −۶ (مرکزی)
 • تابستانی (DST): یوتی‌سی −۵ (سی‌دی‌تی)
حوزه کنگره: یکم
وبگاه: www.co.faribault.mn.us
شهرستان فریبلت، مینه‌سوتا (به انگلیسی: Faribault County, Minnesota) شهرستانی در ایالات متحده آمریکا است که در مینه‌سوتا واقع شده‌است.
پروتکل اصلی سیستم پنجره اکس

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

اکس از یک مدل سرویس‌گیرنده-سرویس‌دهنده برخوردار است. سرور اکس برنامه‌ایست که بر روی رایانه‌ای که دارای نمایشگر و کیبورد است، نصب می‌شود. سرور اکس درخواست‌ها را از کلاینت‌ها دریافت کرده، پس از پردازش، آن‌ها را بر روی صفحه‌نمایش (یا دیگر دستگاه‌های خروجی) نمایش می‌دهد. همچنین سرور اکس اطلاعات را از ماوس و کیبورد و دیگر دستگاه‌های ورودی دریافت کرده، آن‌ها را برای کلاینت‌ها می‌فرستد. کلاینت‌ها همان برنامه‌های کاربردی مانند فایرفاکس، لیبره‌آفیس و ... هستند. ارتباط بین کلاینت‌ها و سرور به کمک پروتکل‌های شبکه انجام می‌شود؛ بنابراین این دو برنامه می‌توانند بر روی کامپیوترهای گوناگون که حتی سیستم‌عامل‌های ناهمسانی هم دارند، نصب شده و سپس با هم تعامل داشته باشند.
ارتباط بین سرور و کلاینت‌ها با مبادله کردن بسته‌هایی بر روی یک کانال مخابراتی انجام می‌شود. اتصال از سوی کلاینت برقرار می‌شود (چگونگی آغاز به کار کلاینت در پروتکل مشخص نشده‌است). همچنین کلاینت نخستین بسته را هم می‌فرستد که این بسته، افزون بر اینکه ترتیب بایت بکاررفته را در خود دارد، اطلاعاتی دربارهٔ نسخهٔ پروتکل و چگونگی اعتبارسنجی که کلاینت دوست دارد سرور از آن استفاده کند را هم در بر می‌گیرد. سرور در پاسخ بسته‌ای را برای کلاینت می‌فرستد که این بسته مشخص می‌کند آیا سرور اتصال کلاینت را پذیرفته‌است یا اینکه آن را رد کرده‌است یا اینکه درخواستی برای اعتبارسنجی کلاینت را به همراه دارد. اگر سرور اتصال را پذیرفته باشد، بسته، داده‌هایی در خود دارد که کلاینت باید در کنش‌های آینده با سرور، آن‌ها را بکار برد. پس از اینکه اتصال برپا شد، چهار گونه بسته در کانال ارتباطی بین سرور و کلاینت جابجا می‌شود:
درخواست: کلاینت اطلاعاتی را از سرور درخواست می‌کند یا اینکه از سرور می‌خواهد تا کاری را انجام دهد.
پاسخ: سرور به درخواست کلاینت پاسخ می‌دهد. تنها برخی از درخواست‌ها پاسخی را به همراه دارند، نه همه آنها.
رویداد: سرور کلاینت را از رخ دادن رویدادی آگاه می‌کند، همچون ورودی ماوس یا صفحه کلید، جابجا شدن یک پنجره، تغییر اندازه آن و دیگر چیزها.
خطا: اگر درخواست غیرمجاز شمرده شود، سرور خطایی را برای کلاینت می‌فرستد. از آنجایی که درخواست‌ها در یک صف جاداده می‌شوند، خطایی که برای یک درخواست فرستاده می‌شود ممکن است بی‌درنگ فرستاده نشوند و دیرکردی در کار باشد.
درخواست‌ها و پاسخ‌ها طول گوناگون و غیرثابتی دارند. این در حالی است که رویدادها یا خطاها از طول ثابت ۳۲ بایتی برخوردارند.
همینکه سرور بسته‌های «درخواست» را دریافت کرد، آن‌ها را به ترتیب شماره‌گذاری می‌کند. به نخستین درخواستی که از سوی کلاینت فرستاده می‌شود، شماره ۱ واگذار می‌شود، دومین درخواست شماره ۲ و همینگونه تا به پایان. اگر درخواستی، یک پاسخ یا یک خطا را به بار آورد، ۱۶ بیت کم‌ارزش از شماره‌ای که به آن درخواست داده شده، در آن بستهٔ «پاسخ» یا «خطا» گنجانده می‌شود تا مشخص باشد که این «پاسخ» یا «خطا» برای کدام درخواست است. این بیت‌ها همچنین در بسته‌های «رویداد» هم برای نشان دادن شمارهٔ درخواستی که سرور سرگرم پردازش آن است یا پردازش آن را به پایان رسانده، گنجانده می‌شوند.
پیکس‌مپ و ترسیم‌پذیرها

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

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

در ادامه نمونه‌ای از چگونگی تعامل و برپایی ارتباط بین یک کلاینت و سرور را مرور می‌کنیم. در این نمونه، کلاینت یک پنجره می‌سازد که جعبه‌ای سیاه‌رنگ در آن جای دارد، برنامه همین که یک کلید فشرده شد، خارج می‌شود. در این مثال، سرور هیچ پاسخی به سوی کلاینت نمی‌فرستد، چرا که درخواست‌های کلاینت پاسخی را در پی ندارند. اما این درخواست‌ها می‌توانند باعث رخ دادن یک خطا شوند:
کلاینت اتصال تازه‌ای را با سرور ایجاد کرده و بسته آغازین را برای سرور می‌فرستد. این بسته اطلاعاتی همچون ترتیب بایت مورد استفاده کلاینت، نسخه پروتکل و ... را در خود دارد.
سرور با فرستادن یک بسته مناسب برای کلاینت، اتصال را می‌پذیرد (در این مثال نیازی به اعتبارسنجی و احراز هویت نیست). این بسته دربرگیرنده شناسه پنجره ریشه (در اینجا 0x0000002b) و بازه‌ای از شناسه‌هاست که کلاینت می‌تواند این شناسه‌ها را برای نام‌گذاری کردن منابع و اشیاء بکار برد.
کلاینت درخواست می‌کند که یک بافت گرافیکی پیش‌فرض با شناسه 0x00200000 ساخته شود. (این درخواست، همانند درخواست‌های دیگر این مثال، پاسخی را در بر ندارد).
کلاینت از سرور می‌خواهد که یک پنجره سطح بالا بسازد. (در این مثال، کلاینت شناسه پنجره ریشه که 0x0000002b بود را به عنوان پنجره پدر مشخص می‌کند، شناسه خود پنجره سطح بالا را 0x00200001 در نظر می‌گیرد، اندازه پنجره را ۲۰۰ در ۲۰۰ پیکسل مشخص می‌کند و از سرور می‌خواهد تا این پنجره را در مختصات (۱۰٫۱۰) رسم کند).
کلاینت از سرور می‌خواهد که یکی از خصوصیات پنجره‌ای با شناسه 0x00200001 را تغییر دهد، و مشخص می‌کند که دوست دارد رویدادهای KeyPress و Expose را دریافت کند. اگر این رویدادها رخ دادند، سرور با فرستادن یک بسته مناسب، کلاینت را آگاه می‌کند.
کلاینت از سرور می‌خواهد تا پنجره‌ای که شناسه آن 0x00200001 است بر روی صفحه نقش شود (بر روی صفحه نشان داده شود).
وقتی که پنجره بر روی صفحه نمایان شد و نیاز به ترسیم محتوای آن بود، سرور رویداد Expose را برای کلاینت می‌فرستد.
در پاسخ به این رویداد، کلاینت با فرستادن یک درخواست PolyFillRectangle از سرور می‌خواهد جعبه‌ای بر روی پنجره رسم شود. شناسه این پنجره 0x00200001 و شناسه بافت گرافیکی آن 0x00200000 است.
اگر پنجره دیگری بر روی پنجره جای گیرد و دوباره از روی آن برداشته شود، با فرض اینکه انباره پشتیبان نگه‌داری نشده باشد:
سرور یک رویداد Expose دیگر ارسال می‌کند تا به کلاینت بگوید که محتوای پنجره باید دوباره رسم شوند.
کلاینت دوباره درخواست PolyFillRectangle را برای سرور می‌فرستد.
اگر کلیدی فشرده شود:
سرور یک رویداد KeyPress برای کلاینت می‌فرستد تا او را از فشرده‌شدن کلیدی آگاه کند.
کلاینت پاسخ مناسبی برای آن رویداد خواهد فرستاد. (در این مثال، به اجرای خودش خاتمه خواهد داد)
اتم‌ها

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

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

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

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

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

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