payamvha/North_RAG huggingface dataset:
کردن این عدد در یک فایل به گونه‌ای که برنامه دیگر بتواند آن را از آن فایل بخواند)، برنامه دیگر هم می‌تواند تا بر روی همان پنجره کاری را انجام دهد. برای نمونه، برنامه گوست‌ویو در سامانه پنجره‌ای اکس از این ویژگی اینگونه بهره می‌برد: این برنامه یک زیرپنجره ساخته، سپس شناسه آن را در یک متغیر محیطی می‌گذارد، سپس برنامه گوست‌اسکریپت را فراخوانی می‌کند، سپس برنامه گوست‌اسکریپت، محتوای یک فایل پست‌اسکریپت را در این پنجره نمایش می‌دهد. معمولاً وقتی که یک کلاینت اتصالش را با سرور قطع می‌کند، منابع به وجود آمده
اتصالش را با سرور قطع می‌کند، منابع به وجود آمده به‌دست آن کلاینت نابود می‌شوند. با این حال، یک کلاینت پیش از پایان دادن به اتصال، می‌تواند از سرور بخواهد که منابع را نابود نکند. رویدادها. رویدادها، بسته‌هایی هستند که از سوی سرور برای کلاینت فرستاده می‌شوند، این بسته‌ها کلاینت را از رخ دادن رویدادی که ممکن است برای کلاینت جالب توجه باشد، آگاه می‌کنند. برای نمونه، هنگامی که کاربر کلیدی را فشار می‌دهد یا بر روی دکمه‌ای کلیک می‌کند، رویدادی برای کلاینت فرستاده می‌شود. رویدادها تنها برای ورودی گرفتن از کاربر و
می‌شود. رویدادها تنها برای ورودی گرفتن از کاربر و فعل و انفعالات او نیستند. برای نمونه، هنگامی که زیرپنجره‌ای در یک پنجره ساخته می‌شود، رویدادی برای آگاه کردن کلاینت از این رخداد، برای آن فرستاده می‌شود. هر رویدادی با یک پنجره در ارتباط است. برای نمونه، اگر کاربر هنگامی که نشانگر ماوس بر روی یک پنجره قرار دارد، روی آن پنجره کلیک کند، رویداد با آن پنجره در ارتباط خواهد بود. بستهٔ رویدادی که برای کلاینت فرستاده می‌شود، شناسه آن پنجره را در بر دارد. یک کلاینت می‌تواند از سرور بخواهد که رویدادی را برای یک
می‌تواند از سرور بخواهد که رویدادی را برای یک کلاینت دیگر بفرستد؛ کلاینت‌ها از این ویژگی برای برقراری ارتباط با یکدیگر استفاده می‌کنند. برای نمونه، هنگامی که کلاینتی از سرور درخواست می‌کند که متن انتخاب‌شده به‌دست کاربر برایش فرستاده شود، یک چنین رویدادی ساخته می‌شود (ممکن است کاربر متن موجود در پنجره‌ای که متعلق به یک کلاینت دیگر است را انتخاب کرده باشد)؛ این رویداد، برای کلاینتی فرستاده می‌شود که پنجره حاوی متن انتخاب‌شده را اداره می‌کند. هنگامی که محتویات بخشی از یک پنجره، نابود شده و سپس دوباره نمایان
بخشی از یک پنجره، نابود شده و سپس دوباره نمایان می‌شود، رویدادی به نام codice_10 برای کلاینت فرستاده می‌شود. محتوای یک پنجره می‌تواند در برخی شرایط نابود شود. برای نمونه اگر یک پنجره، بر روی پنجره دیگری جای بگیرد و همه یا بخشی از آن را بپوشاند، محتوای پنجره پوشیده شده نابود خواهد شد. البته این هنگامی است که سرور انباره پشتیبان برای آن پنجره را نگه‌داری نکرده باشد. سرور تضمین نمی‌کند که حتماً یک انباره پشتیبان نگه‌داری می‌کند، اما تضمین می‌کند که هر گاه نیاز به ترسیم دوباره محتوای یک پنجره بود، رویدادی را
به ترسیم دوباره محتوای یک پنجره بود، رویدادی را برای کلاینت بفرستد. بسیاری از رویدادها تنها هنگامی برای کلاینت فرستاده می‌شوند که کلاینت از پیش آمادگی خود را برای دریافت آن‌ها اعلام کرده باشد و مایل به دریافت آن رویدادها بوده باشد. دلیل این کار این است که شاید تنها چند گونه رویداد خاص برای برخی از کلاینت‌ها جالب توجه باشد و کلاینت‌ها نخواهند به همه آن‌ها پاسخ دهند. برای نمونه، یک کلاینت ممکن است تنها بخواهد از رویدادهای صفحه‌کلید آگاه شود و علاقه‌ای به رویدادهای ماوس نداشته باشد. با این حال، رویدادهایی
ماوس نداشته باشد. با این حال، رویدادهایی هستند که حتی اگر کلاینت از پیش آمادگی خود را برای دریافت آن‌ها نشان نداده باشد، باز هم برای کلاینت فرستاده می‌شوند. کلاینت‌ها با تنظیم کردن یکی از خصوصیات پنجره، مشخص می‌کنند که علاقه‌مند به دریافت کردن چه رویدادهایی هستند. برای نمونه، برای ترسیم دوباره پنجره‌ای که محتوای آن نابود شده، کلاینت باید رویداد codice_10 را دریافت و پذیرش کند (این رویداد برای همین کار در نظر گرفته شده و کلاینت را آگاه می‌کند که محتوای پنجره نیازمند ترسیم دوباره است). با این حال، این رویداد
نیازمند ترسیم دوباره است). با این حال، این رویداد تنها هنگامی برای کلاینت فرستاده می‌شود که کلاینت از پیش اعلام کرده باشد که می‌خواهد آن را دریافت کند. این کار با تنظیم کردن خصوصیت ماسک رویداد پنجره، با یک مقدار مناسب انجام می‌شود. کلاینت‌های گوناگون می‌توانند رویدادهای مرتبط با یک پنجره یکسان را دریافت کنند. آن‌ها حتی می‌توانند ماسک رویداد آن پنجره را به گونهٔ متفاوتی مقداردهی کنند و بدین گونه، هر کدام رویدادهای گوناگونی را دریافت کنند. برای نمونه، یک کلاینت شاید بخواهد تنها رویدادهای مرتبط با صفحه‌کلیدی
شاید بخواهد تنها رویدادهای مرتبط با صفحه‌کلیدی که برای یک پنجره رخ می‌دهد را دریافت کند، در حالی که کلاینت دیگر دوست دارد تنها رویدادهای مرتبط با ماوس برای همان پنجره را دریافت کند. این کار برای این شدنی است که سرور برای هر پنجره، ماسک رویداد جداگانه‌ای را به ازای هر کلاینت نگه‌داری می‌کند. با این حال، برخی از رویدادها تنها می‌توانند در هر زمان به‌دست یک کلاینت دریافت شوند و کلاینت‌های دیگر نمی‌توانند همزمان همان رویداد را دریافت کنند. این رویدادها، گزارش‌هایی را دربارهٔ کلیک کردن دکمه‌های ماوس و همچنین
را دربارهٔ کلیک کردن دکمه‌های ماوس و همچنین تغییرات مرتبط با مدیریت پنجره را می‌فرستند. برنامه codice_12 رویدادهای مرتبط با یک پنجره را نمایش می‌دهد. دستور codice_13 همه رویدادهای ممکن برای پنجره‌ای با شناسه codice_14 را دریافت کرده و چاپ می‌کند. نمونه. در ادامه نمونه‌ای از چگونگی تعامل و برپایی ارتباط بین یک کلاینت و سرور را مرور می‌کنیم. در این نمونه، کلاینت یک پنجره می‌سازد که جعبه‌ای سیاه‌رنگ در آن جای دارد، برنامه همین که یک کلید فشرده شد، خارج می‌شود. در این مثال، سرور هیچ پاسخی به سوی کلاینت
می‌شود. در این مثال، سرور هیچ پاسخی به سوی کلاینت نمی‌فرستد، چرا که درخواست‌های کلاینت پاسخی را در پی ندارند. اما این درخواست‌ها می‌توانند باعث رخ دادن یک خطا شوند: اگر پنجره دیگری بر روی پنجره جای گیرد و دوباره از روی آن برداشته شود، با فرض اینکه انباره پشتیبان نگه‌داری نشده باشد: اگر کلیدی فشرده شود: رنگ‌ها. در سطح پروتکل، رنگ‌ها به شکل اعداد صحیح ۳۲ بیتی بدون علامت نمایش می‌یابند که "pixelvalue" نامیده می‌شوند. عناصر زیر بر روی نمایش رنگ‌ها تأثیر دارند: در ساده‌ترین حالت، رنگ‌نگاشت جدولی است که هر سطر
در ساده‌ترین حالت، رنگ‌نگاشت جدولی است که هر سطر آن حاوی یک سه‌تایی آرجی‌بی است. یک pixelvalue به نام x، نشان‌دهنده رنگی است که در سطر xام جدول قرار گرفته‌است. اگر کلاینت قادر باشد مدخل‌های رنگ‌نگاشت را تغییر دهد، این بازنمایش جدید توسط "کلاس بصری" codice_30 نشان داده می‌شود. کلاس codice_31 هم کلاسی مشابه است، اما در این کلاس کلاینت نمی‌تواند مدخل‌های رنگ‌نگاشت را تغییر دهد. حدود ۶ کلاس بصری وجود دارد که هر کدام از آن‌ها روش متفاوتی را برای نمایش دادن سه‌تایی RGB در یک pixelvalue دارند. codice_30 و
سه‌تایی RGB در یک pixelvalue دارند. codice_30 و codice_31 دو تا از این کلاس‌ها هستند. codice_34 و codice_35 هم دو تای دیگر هستند فرق آن‌ها در این است که این جدول‌ها فقط میزان شدت رنگ قهوه‌ای را نمایش می‌دهند. دو کلاس بصری باقی‌مانده با کلاس‌هایی که در بالا معرفی شدند متفاوت هستند، چرا که آن‌ها pixelvalueها را به سه قسمت تقسیم می‌کنند و برای تعیین کردن شدت رنگ‌های آبی، قرمز و سبز، از سه جدول مجزا برای هر کدام استفاده می‌کنند. بر طبق این نحوه نمایش رنگ، یک pixelvalue به صورت زیر به یک سه‌تایی RGB تبدیل
یک pixelvalue به صورت زیر به یک سه‌تایی RGB تبدیل می‌شود: این سازوکار نیازمند آن است که رنگ‌نگاشت از سه جدول مجزا تشکیل شده باشد و به ازای هر رنگ اولیه، یک جدول مجزا وجود داشته باشد. نتیجه این تبدیل، همچنان یک سه‌تایی از مقادیری است که مشخص‌کننده شدت رنگ‌ها هستند. کلاس‌های بصری که برای نمایش این تبدیل جدید استفاده می‌شود codice_36 و codice_37 هستند و فرق آن‌ها در این است که آیا کلاینت می‌تواند رنگ‌نگاشت‌ها را تغییر دهد یا خیر. این شش سازوکار برای نمایش رنگ‌ها به وسیلهٔ pixelvalueها، همگی نیازمند پارامترهای
به وسیلهٔ pixelvalueها، همگی نیازمند پارامترهای بیشتری هستند تا بتوانند کار کنند. این پارامترها در یک "گونه بصری" گردآوری می‌شوند. یک گونه بصری، حاوی یک کلاس بصری و دیگر پارامترهای مورد نیاز برای نمایش رنگ‌هاست. هر سرور یک دسته ثابت از گونه‌های بصری دارد که هر کدام شناسه عددی مخصوص به خود را دارند. این شناسه‌ها اعداد صحیح ۳۲ بیتی بدون علامت هستند، اما الزاماً متفاوت با شناسه منابع یا اتم‌های (بعدا تشریح می‌شود) دیگر نیستند و ممکن است با آن‌ها همپوشانی داشته باشند. وقتی که اتصال یک کلاینت توسط سرور پذیرفته
باشند. وقتی که اتصال یک کلاینت توسط سرور پذیرفته می‌شود، بسته پذیرشی که از طرف سرور برای کلاینت ارسال می‌شود حاوی دنباله‌ای از بلاک‌هاست که هر کدام از این بلاک‌ها، حاوی اطلاعاتی دربارهٔ یک صفحه‌نمایش هستند. بلاک متناظر با هر صفحه‌نمایش، حاوی فهرستی از بلاک‌های دیگر است که هر کدام از این بلاک‌ها، مربوط به عمق رنگ خاصی است که توسط آن صفحه‌نمایش پشتیبانی می‌شود. این فهرست، به ازای هر یک از عمق رنگ‌های مورد پشتیبانی، حاوی فهرستی از گونه‌های بصری است. در نتیجه، هر صفحه نمایش تعدادی عمق رنگ دارد که هر کدام از
هر صفحه نمایش تعدادی عمق رنگ دارد که هر کدام از این عمق رنگ‌ها، دارای چند گونه بصری هستند. هر گونه بصری را می‌توان برای چندین صفحه‌نمایش با عمق‌های مختلف مورد استفاده قرار داد. بسته پذیرش به ازای هر گونه بصری، هم حاوی شناسه آن گونه بصری هست و هم حاوی پارامترهای واقعی که در آن گونه بصری وجود دارد (کلاس بصری و موارد دیگر). کلاینت‌ها این اطلاعات را در خود ذخیره می‌کنند، چرا که بعداً نمی‌توانند آن‌ها را درخواست دهد. علاوه بر آن، کلاینت‌ها نمی‌توانند گونه‌های بصری را تغییر داده یا گونه‌های بصری جدید ایجاد کنند.
را تغییر داده یا گونه‌های بصری جدید ایجاد کنند. درخواستی که برای ایجاد کردن یک پنجره جدید برای سرور ارسال می‌شود، حاوی عمق و شناسه گونه بصری‌ای است که باید برای نمایش دادن رنگ‌ها در آن پنجره، مورد استفاده قرار گیرد. رنگ‌نگاشت‌ها بدون توجه به اینکه سخت‌افزاری که صفحه نمایش را کنترل می‌کند (همانند کارت گرافیک) از یک پالت استفاده می‌کند یا نه، بکار برده می‌شوند. پالت هم جدولی است که برای نمایش دادن رنگ‌ها بکار برده می‌شود. حتی اگر سخت‌افزار از یک پالت استفاده نکند، سرورهاباز هم از رنگ‌نگاشت‌ها استفاده
نکند، سرورهاباز هم از رنگ‌نگاشت‌ها استفاده می‌کنند. هنگامی که سخت‌افزار از پالت بهره می‌برد، می‌توان تنها شمار محدودی از رنگ‌نگاشت‌ها را بکار گرفت. یک رنگ‌نگاشت هنگامی به کار گرفته می‌شود که سخت‌افزار بر طبق آن رنگ‌ها را نشان می‌دهد. یک کلاینت می‌تواند از سرور بخواهد که یک رنگ‌نگاشت را بکار بگیرد. با این حال، این کار ممکن است نیازمند از کار انداختن رنگ‌نگاشت دیگری باشد. این کار باعث می‌شود پنجره‌هایی که از آن رنگ‌نگاشت از کار انداخته شده‌استفاده می‌کنند، با رنگ‌های مناسب خود نمایش نیابند که به این پدیده
با رنگ‌های مناسب خود نمایش نیابند که به این پدیده color flashing یا technicolor می‌گویند. این مشکل می‌تواند با استفاده از "رنگ‌نگاشت‌های استاندارد" رفع شود. رنگ‌نگاشت‌های استاندارد، رنگ‌نگاشت‌هایی هستند که در آن‌ها رابطه‌ای از پیش‌تعیین‌شده بین pixelvalueها و رنگ‌ها وجود دارد. به لطف این خصیصه رنگ‌نگاشت‌های استاندارد، برنامه‌های مختلف می‌توانند آن‌ها را بکار گیرند. به‌وجود آوردن رنگ‌نگاشت‌ها در قرارداد ICCCM بحث شده‌است. رنگ‌نگاشت‌های استاندارد توسط ICCCM و اکس‌لیب تنظیم می‌شوند. اتم‌ها. اتم‌ها اعداد ۳۲
و اکس‌لیب تنظیم می‌شوند. اتم‌ها. اتم‌ها اعداد ۳۲ بیتی هستند که رشته‌ها را نمایش می‌دهند. سازندگان پروتکل، اتم‌ها را به این دلیل معرفی کردند، که اتم‌ها رشته‌ها را به شکلی کوتاه و با اندازه‌ای ثابت نمایش می‌دهند. در حالی که یک رشته می‌تواند طول دلخواهی داشته باشد، یک اتم همیشه اندازه ثابت ۳۲ بیتی دارد. در مواردی که بسته‌هایی با یک رشته یکسان باید به صورت چند باره فرستاده شود، می‌توان با اتم‌ها، از شبکه به گونه بهینه‌تر سود جست. بسته‌های نوع رویداد که اندازه ثابت ۳۲ بایتی دارند، می‌توانند اتم‌ها را در خود جای
۳۲ بایتی دارند، می‌توانند اتم‌ها را در خود جای دهند، اما ممکن است یک رشته متنی به اندازه‌ای بزرگ باشد که نتوان آن را در بسته‌های رویداد گنجاند. به گونه دقیقتر می‌توان گفت که اتم‌ها، شناسه‌هایی برای رشته‌هایی که در سرور ذخیره شده‌اند، هستند. آن‌ها همانند شناسه‌های منابع (پنجره، پیکس‌مپ و غیره) هستند. اما دو تفاوت با آن‌ها دارند. یکی اینکه شناسه اتم‌ها به‌دست سرور گزیده می‌شود و کلاینت در گزینش آن‌ها نقشی ندارد. به عبارتی دیگر، هنگامی که کلاینت درخواست ساختن یک اتم تازه را می‌دهد، تنها رشته‌ای که قرار است
یک اتم تازه را می‌دهد، تنها رشته‌ای که قرار است ذخیره شود را برای سرور می‌فرستد، نه شناسه آن اتم را. این شناسه را سرور گزینش کرده و به صورت یک پاسخ برای کلاینت می‌فرستد. دومین فرق مهم بین اتم‌ها و منابع این است که اتم‌ها با کلاینت‌ها در ارتباط نیستند و به آن‌ها وابسته نیستند. هنگامی که اتم‌ها در سرور ساخته می‌شوند، تا هنگامی که سرور خاموش یا راه‌اندازی دوباره نشده، در همان‌جا باقی خواهند ماند (منابع به گونه پیشفرض چنین رفتاری ندارند و وابسته به کلاینت هستند). از آنجا که اتم‌ها یک نوع شناسه هستند، یکتا هم
از آنجا که اتم‌ها یک نوع شناسه هستند، یکتا هم هستند. با این حال، یک اتم و شناسه یک منبع می‌توانند با یکدیگر همپوشانی داشته باشند. رشته‌ای که به یک اتم داده شده، "نام اتم" نامیده می‌شود. پس از اینکه یک اتم ساخته شد، نام آن را نمی‌توان تغییر داد و دو اتم هم نمی‌توانند نام یکسانی داشته باشند. در نتیجه، معمولاً از نام یک اتم برای اشاره به آن اتم استفاده می‌شود. «اتم ABCD» به شکل دقیقتر یعنی «اتمی که رشته ABCD به آن اختصاص یافته است». یک کلاینت، هم می‌تواند از سرور درخواست کند که یک اتم تازه بسازد و هم می‌تواند
درخواست کند که یک اتم تازه بسازد و هم می‌تواند با دادن یک رشته به سرور، شناسه اتم آن را دریافت کند. برخی از اتم‌ها "از قبل تعریف شده" هستند. (سرور آن‌ها را با یک شناسه و رشته معین از قبل تعریف کرده‌است). اتم‌ها را می‌توان برای اهداف گوناگونی بکار برد. یکی از رایج‌ترین استفاده از اتم‌ها، برقرار کردن ارتباط بین دو یا چند کلاینت است که همگی به یک سرور یکسان متصل شده‌اند. آن‌ها به همراه ویژگی‌های پنجره‌ها استفاده می‌شوند که در ادامه تشریح می‌شود. با استفاده از برنامه codice_38 می‌توان فهرست همه اتم‌های موجود
برنامه codice_38 می‌توان فهرست همه اتم‌های موجود در سرور را چاپ کرد. این برنامه برای هر اتم، شناسه آن (که یک عدد است) و نام آن (که یک رشته است) را چاپ می‌کند. خصیصه‌ها. هر پنجره، یک سری ویژگی از پیش تعریف شده و یک سری خصیصه دارد که همه آن‌ها در سرور ذخیره می‌شوند و کلاینت می‌تواند برای دسترسی به آنها، درخواستی را برای سرور بفرستد. ویژگی‌ها، اطلاعاتی دربارهٔ یک پنجره هستند، مانند اندازه، مکان، رنگ پس‌زمینه و دیگر جیزها. خصیصه‌ها، اطلاعات دلخواهی هستند که به یک پنجره چسبیده می‌شوند. برخلاف ویژگی‌ها، خصیصه‌ها
پنجره چسبیده می‌شوند. برخلاف ویژگی‌ها، خصیصه‌ها معنی خاصی در سطح پروتکل اکس ندارند. یک کلاینت می‌تواند هر گونه اطلاعات دلخواهی را در خصیصه یک پنجره ذخیره کند. یک خصیصه با نام، نوع و مقدار آن شناخته می‌شود. خصیصه‌ها همانند متغیرها در زبان‌های برنامه‌نویسی دستوری هستند، که یک کلاینت می‌تواند خصیصه تازه‌ای را با نام و نوع دلخواه ساخته و مقداری را در آن بگذارد. خصیصه‌ها مخصوص همان پنجره هستند: دو خصیصه همنام می‌تواند در دو پنجره گوناگون وجود داشته باشد، در حالی که مقدار و نوع آن‌ها با یکدیگر ناهمسان است. نام،
که مقدار و نوع آن‌ها با یکدیگر ناهمسان است. نام، نوع و مقدار یک خصیصه به صورت رشته، یا به شکل دقیق‌تر، اتم هستند. رشته‌ها در سرور ذخیره شده و کلاینت می‌تواند با شناسه‌ها به آن‌ها دسترسی داشته باشد. یک کلاینت می‌تواند با شناسهٔ اتمی که دربرگیرنده نام یک خصیصه است، به آن خصیصه دسترسی داشته باشد. خصیصه‌ها بیشتر برای ارتباطات بین کلاینتی بکار برده می‌شوند. برای نمونه، یک خصیصه به نام codice_39 (این خصیصه توسط اتمی که رشته اختصاص یافته به آن codice_40 است نامگذاری شده‌است) هست که برای ذخیره کردن نام پنجره‌ها
شده‌است) هست که برای ذخیره کردن نام پنجره‌ها بکار برده می‌شود. مدیر پنجره‌ها معمولاً این خصیصه را می‌خوانند و سپس آن را در نوار عنوان پنجره نمایش می‌دهند. برخی از انواع ارتباطات بین کلاینتی، از خصیصه‌های پنجره ریشه استفاده می‌کنند. برای نمونه، بر پایه مشخصاتی که فری‌دسکتاپ برای مدیر پنجره‌ها تعریف کرده، مدیر پنجره‌ها باید شناسه پنجره‌ای که هم‌اکنون فعال است و فوکوس را در اختیار دارد را در یکی از خصیصه‌های پنجره ریشه به نام codice_41 ذخیره کنند. منابع اکس که حاوی پارامترهای برنامه‌ها هستند هم در خصیصه‌های
حاوی پارامترهای برنامه‌ها هستند هم در خصیصه‌های پنجره ریشه ذخیره می‌شوند. به این گونه، همه کلاینت‌ها می‌توانند به این خصیصه‌ها دسترسی داشته باشند، حتی اگر این کلاینت‌ها بر روی رایانه‌های گوناگون اجرا شوند. برنامه codice_42 خصیصه‌های یک پنجره دلخواه را نمایش می‌دهد. دستور codice_43، نام، نوع و مقدار همه خصیصه‌های پنجره ریشه را چاپ می‌کند. نگاشت کردن. در سامانه پنجره‌ای اکس، هر کلیدی که بر روی دستگاه‌های ورودی از جمله ماوس و کیبورد وجود دارد، یک عدد منحصربفرد مابین ۸ تا ۲۵۵ دارد که به آن keycode می‌گویند. یک
مابین ۸ تا ۲۵۵ دارد که به آن keycode می‌گویند. یک keycode تنها یک کلید ویژه را شناسایی می‌کند، نه یک کاراکتر یا لفظ (مانند Page up) که بر روی کلید چاپ شده‌اند را. درعوض هر کدام از این الفاظ یا کاراکترها با یک keysym شناسایی می‌شوند. درحالی‌که keycode تنها به کلیدی که فشرده شده‌است وابسته است، یک keysym ممکن است به اینکه دکمه Shift یا یک اصلاح‌گر دیگر هم فشرده شده باشد، بستگی داشته باشد. هنگامی که کلیدی فشرده یا رها می‌شود، سرور رویدادهایی از نوع codice_20 یا codice_45 را برای کلاینت‌های مورد نظر می‌فرستد.
codice_45 را برای کلاینت‌های مورد نظر می‌فرستد. این رویدادها داده‌های زیر را در خود دارند: بنابراین سرور keycode و وضعیت اصلاح‌گرها را بدون اینکه تلاش کند خود آن‌ها را به یک کاراکتر ویژه ترجمه کند، برای کلاینت می‌فرستد و وظیفه ترجمه و تفسیر آن‌ها را بر دوش کلاینت واگذار می‌کند. برای نمونه، یک کلاینت ممکن است رویدادی مبنی بر اینکه یک کلید ویژه در حالی فشرده شده‌است که دکمه شیفت هم پایین نگه داشته شده، دریافت کند. اگر در حالت معمول این کلید خاص، کاراکتر 'a' را تولید می‌کرده، کلاینت (و نه سرور) این رویداد را
تولید می‌کرده، کلاینت (و نه سرور) این رویداد را به منزله وارد شدن کاراکتر 'A' تلقی می‌کند. درحالی‌که ترجمه keycodeها به keysym به‌دست کلاینت انجام می‌شود، جدولی که ارتباط بین آن‌ها را مشخص می‌کند در سرور نگهداری می‌شود. ذخیره کردن این جدول در سرور که یک جای عمومی و مرکزی است، این امکان را فراهم می‌کند تا همه کلاینت‌ها بتوانند به آن دسترسی داشته باشند. کلاینت‌ها تنها از سرور، نگاشت کردن keycodeها به keysymها را درخواست می‌کنند و از آن برای رمزگشایی کردن keycodeها و اصلاح‌گرها به یک keysym استفاده می‌کنند.
و اصلاح‌گرها به یک keysym استفاده می‌کنند. با این حال، کلاینت‌ها می‌توانند این نگاشت کردن را به خواست خودشان تغییر دهند. یک اصلاح‌گر کلیدی است که هنگامی فشرده می‌شود، چگونگی تفسیر شدن کلیدها را تغییر می‌دهد. یکی از اصلاح‌گرهای رایج، کلید شیفت است. وقتی کلیدی که در حالت معمول کاراکتر 'a' را تولید می‌کند، به همراه کلید شیفت فشرده می‌شود، باعث تولید شدن یک کاراکتر بزرگ 'A' می‌شود. دیگر اصلاح‌گرهای رایج، کلید آلت، کنترل و متا هستند. سرور اکس حداکثر با هشت عدد اصلاح‌گر کار می‌کند. ضمناً، هر اصلاح‌گر می‌تواند
اصلاح‌گر کار می‌کند. ضمناً، هر اصلاح‌گر می‌تواند بیش از یک کلید داشته باشد. این کار بایسته است، چرا که بیشتر کیبوردها دو کلید برای برخی از اصلاح‌گرها دارند. برای نمونه، بیشتر کیبوردها دو کلید شیفت دارند (یکی در سمت چپ و دیگری در سمت راست). این دو کلید، در هنگام فشرده‌شدن هر کدام keycode ویژه و متفاوت از یکدیگری را تولید می‌کنند، اما سرور اکس هر دو آن‌ها را به عنوان اصلاح‌گر شیفت می‌شناسد. سرور اکس برای هر کدام از این هشت اصلاح‌گر، فهرستی از keycodeها را نگه می‌دارد که آن‌ها را به عنوان آن اصلاح‌گر تفسیر
می‌دارد که آن‌ها را به عنوان آن اصلاح‌گر تفسیر می‌کند. برای نمونه، اگر در فهرست اولین اصلاح‌گر (اصلاح‌گر شیفت)، یک kecode با مقدار codice_46 وجود داشته باشد، آنگاه سرور کلیدی که باعث تولید شدن keycodeای با مقدار codice_46 می‌شود را به عنوان یک کلید شیفت در نظر می‌گیرد. هرچند که فهرست‌های مربوط به نگاشت کردن اصلاح‌گرها در سرور نگهداری می‌شود، اما هر کلاینتی می‌تواند آن‌ها را به خواست خود تغییر دهد. برای نمونه، یک کلاینت می‌تواند درخواست دهد که کلید F1 به فهرست اصلاح‌گر شیفت افزوده شود. با این کار، کلید F1
اصلاح‌گر شیفت افزوده شود. با این کار، کلید F1 همانند یک کلید شیفت کار می‌کند. با این حال، keycode اصلی متناظر با F1، همچنان در هنگام فشرده‌شدن این کلید تولید می‌شود. در نتیجه، F1 همانگونه کار می‌کند که پیش از آن کار می‌کرده (برای نمونه ممکن است یک پنجره Help در هنگام فشرده شدن F1 باز شود)، اما همچنین به عنوان یک کلید شیفت هم کار می‌کند (برای نمونه فشردن کلید 'a' به همراه F1 می‌تواند باعث تولید شدن یک کاراکتر 'A' در یک ویرایشگر متن شود). سرور اکس همچنین سازوکار برای نگاشت کردن دکمه‌های ماوس دارد. با این
برای نگاشت کردن دکمه‌های ماوس دارد. با این حال، دکمه‌های ماوس تنها می‌توانند با یکدیگر جایگذاری شوند. این کار به ویژه برای تعویض کردن دکمه‌های چپ و راست برای استفاده آسان‌تر توسط افراد راست‌دست و چپ‌دست سودمند است. قاپیدن رویدادها. قاپیدن رویدادها وضعیتی است که در آن تمام رویدادهای مرتبط با کیبورد و ماوس، تنها برای یک کلاینت خاص ارسال می‌شود. به عبارت دیگر، یک کلاینت رویدادهایی که در اصل برای کلاینت‌های دیگر هستند را از آن‌ها می‌قاپد. یک کلاینت می‌تواند درخواست قاپیدن رویدادهای کیبورد، ماوس یا هر دو را از
قاپیدن رویدادهای کیبورد، ماوس یا هر دو را از سرور درخواست کند. اگر سرور درخواست کلاینت را برآورده سازد، آنگاه تمام رویدادهای مرتبط با ماوس/کیبورد، برای آن کلاینت ارسال می‌شود؛ تا وقتی که کلاینت grab را رها کند. کلاینت‌های دیگر این رویدادها را دریافت نخواهند کرد. کلاینت در هنگام قاپیدن رویدادها، "پنجره قاپیدن" را هم مشخص می‌کند. در این حالت، تمام رویدادها طوری برای کلاینت ارسال می‌شوند که انگار مرتبط با آن پنجره هستند. با این حال دیگر کلاینت‌ها هیچ رویدادی را دریافت نمی‌کنند، حتی اگر آن رویدادها را در پنجره
دریافت نمی‌کنند، حتی اگر آن رویدادها را در پنجره قاپیدن انتخاب کرده باشند. دو نوع قاپیدن وجود دارد: کلاینت‌ها می‌توانند بر روی کیبورد، مکان‌نما، یا هر دو آن‌ها درخواست قاپیدن رویدادها را بکنند. یک درخواست قاپیدن، ممکن است حاوی درخواستی برای "فریز کردن" صفحه‌کلید یا مکان‌نما باشد. تفاوت گرب کردن (قاپیدن رویدادها) و فریز کردن در این است که در گرب، گیرندهٔ رویدادها تغییر می‌کند و رویدادها به کلاینتی غیر از کلاینت اصلی‌شان تحویل داده می‌شوند، در حالی که فریز کردن باعث می‌شود تا رویدادها به هیچ گیرنده‌ای تحویل
باعث می‌شود تا رویدادها به هیچ گیرنده‌ای تحویل داده نشوند. وقتی که دستگاهی فریز می‌شود، رویدادهایی که آن دستگاه تولید می‌کند در یک صف ذخیره می‌شوند تا بعدها پس از اتمام شدن عمل فریز، به گیرنده تحویل داده شوند. پارامتر دیگری هم در رابطه با رویدادهای مکان‌نما وجود دارد که در تحویل دادن رویدادها مؤثر است: ماسک رویداد، که مشخص می‌کند چه نوع رویدادهایی باید تحویل داده شوند و از چه نوع رویدادهایی باید صرف نظر شود. دیگر موارد. رویدادها و درخواست‌های دیگری هم در پروتکل وجود دارد. برخی از درخواست‌ها، در مورد رابطهٔ
وجود دارد. برخی از درخواست‌ها، در مورد رابطهٔ پدری بین پنجره‌ها هستند. یک کلاینت می‌تواند درخواست کند تا پدر یک پنجره تغییر یابد. یا می‌تواند اطلاعاتی را در مورد پدر یک پنجره درخواست کند. برخی دیگر از درخواست‌ها، دربارهٔ انتخاب‌ها هستند، با این حال، بیشتر این درخواست‌ها به‌دست پروتکل‌های دیگری جز پروتکل اصلی تعریف و مشخص می‌شوند. دسته دیگر از درخواست‌ها، درخواست‌های مرتبط با فوکوس ورودی و شکل مکان‌نما هستند. همچنین یک کلاینت می‌تواند درخواست دهد مالک یک منبع (پنجره، pixmap و ...)، از بین برود که خود باعث
(پنجره، pixmap و ...)، از بین برود که خود باعث از بین رفتن ارتباط سرور با آن می‌شود. در نهایت، یک کلاینت می‌تواند یک درخواست از نوع بدون عملیات را برای سرور بفرستد. اضافات و افزونه‌ها. پروتکل سامانه پنجره‌ای اکس به گونه گسترش‌پذیر ساخته شده‌است. این پروتکل سازوکاری را فراهم می‌کند که یک کلاینت به کمک آن می‌تواند از وجود داشتن یک افزونه مطمئن شود. همچنین پروتکل اصلی، چگونگی ساخته شدن بسته‌های درخواست، رویداد و خطایی که متعلق به یک افزونه هستند را هم مشخص می‌کند. یک کلاینت می‌تواند برای داده‌هایی که وابسته و
یک کلاینت می‌تواند برای داده‌هایی که وابسته و مرتبط به یک افزونه دلخواه هستند، فهرست همه افزونه‌های موجود را درخواست کند. بسته‌هایی که متعلق به یک افزونه هستند، مشابه همان بسته‌های اصلی پروتکل هستند. پروتکل اصلی، مشخص می‌کند که بسته‌های نوع درخواست، رویداد یا خطا، باید دربرگیرنده یک عدد صحیح باشند که این عدد صحیح، نوع آن بسته را مشخص می‌کند (برای نمونه، درخواست‌هایی که برای ساختن یک پنجره تازه بکار می‌روند، با عدد ۱ شماره‌گذاری می‌شوند). بازه‌ای از این اعداد صحیح برای افزونه‌ها رزرو شده‌است. اعتبارسنجی و
صحیح برای افزونه‌ها رزرو شده‌است. اعتبارسنجی و تأیید هویت. در ابتدا، وقتی که کلاینت می‌خواهد ارتباطی را با سرور برقرار کند، سرور می‌تواند ارتباط را بپذیرد، آن را رد کند، یا کلاینت را اعتبارسنجی کند و در صورت تأیید شدن هویت کلاینت، ارتباط با آن را بپذیرد. روش‌های گوناگونی برای اعتبارسنجی هست. یک درخواست اعتبارسنجی، روشی که باید برای اعتبارسنجی بکار برده شود را در خود دارد. پروتکل، مراحل انجام اعتبارسنجی را مشخص و تعریف نمی‌کند، چرا که مراحل اعتبارسنجی بستگی به روشی دارد که برای اعتبارسنجی بکار برده می‌شود،
به روشی دارد که برای اعتبارسنجی بکار برده می‌شود، پروتکل تنها مشخص می‌کند که این فرایند، یا با فرستادن بسته پذیرش یا با فرستادن بسته عدم پذیرش از سوی سرور، پایان می‌یابد. در طول یک فعل و انفعال عادی بین یک کلاینت و سرور، تنها درخواست‌هایی که با اعتبارسنجی در ارتباط هستند، در مورد "روش دسترسی مبتنی بر میزبان" هستند. به‌طور دقیق‌تر، یک کلاینت می‌تواند از سرور بخواهد که این روش فعال باشد یا نه، و همین‌طور می‌تواند از سرور بخواهد که فهرستی از میزبان‌هایی (کلاینت‌هایی) که مجاز به برقراری ارتباط هستند را بخواند
که مجاز به برقراری ارتباط هستند را بخواند یا تغییر دهد. برنامه‌های عادی از این‌گونه درخواست‌ها استفاده نمی‌کنند، این درخواست‌ها توسط برنامه codice_48 استفاده می‌شوند. این برنامه از این درخواست‌ها به این منظور استفاده می‌کند تا به یک کاربر یا یک اسکریپت، اجازه دسترسی داشتن به سرور اکس را بدهد. اکس‌لیب و دیگر کتابخانه‌های مرتبط. بیشتر برنامه‌های کلاینت با استفاده از کتابخانه اکس‌لیب با سرور ارتباط برقرار می‌کنند. در واقع، عمده کلاینت‌ها از کتابخانه‌های جی‌تی‌کی، کیوت، موتیف و ... استفاده می‌کنند که این
کیوت، موتیف و ... استفاده می‌کنند که این کتابخانه‌ها خود در واقع در سطوح پایین‌تر از اکس‌لیب برای برقراری ارتباط با سرور استفاده می‌کنند. استفاده از اکس‌لیب اثرات زیر را به‌دنبال دارد: کتابخانه‌های سطح بالاتر همانند Xt (که موتیف و Xaw آن را بکار می‌برند)، به برنامه‌های کلاینت اجازه می‌دهد تا برای برخی از رویدادها، توابع بازفراخوانی را در نظر بگیرند. این کتابخانه به صف رویدادها سرکشی می‌کند و در هنگام نیاز، توابع منظور شده را اجرا می‌کند. برخی از رویدادها، همانند رویدادهایی که نیازمند ترسیم دوباره یک پنجره