.\" $Xorg: Xnest.man,v 1.3 2000/08/17 19:53:28 cpqbld Exp $
.\" Copyright (c) 1993, 1994  X Consortium
.\"
.\" Permission is hereby granted, free of charge, to any person obtaining
.\" a copy of this software and associated documentation files (the
.\" "Software"), to deal in the Software without restriction, including
.\" without limitation the rights to use, copy, modify, merge, publish,
.\" distribute, sublicense, and/or sell copies of the Software, and to
.\" permit persons to whom the Software is furnished to do so, subject to
.\" the following conditions:
.\"
.\" The above copyright notice and this permission notice shall be included
.\" in all copies or substantial portions of the Software.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
.\" IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR
.\" OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
.\" ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
.\" OTHER DEALINGS IN THE SOFTWARE.
.\"
.\" Except as contained in this notice, the name of the X Consortium shall
.\" not be used in advertising or otherwise to promote the sale, use or
.\" other dealings in this Software without prior written authorization
.\" from the X Consortium.
.\"
.\" $XFree86: xc/programs/Xserver/hw/xnest/Xnest.man,v 1.6 2001/01/27 18:21:00 dawes Exp $
.\"
.TH Xnest 1 "xorg-server 21.1.24" "X Version 11"
.SH "نام (NAME)"
Xnest \- یک کارساز X تودرتو
.SH "خلاصه دستور (SYNOPSIS)"
.B Xnest
[
.I گزینه‌ها
]
.SH "توضیحات (DESCRIPTION)"
.B Xnest
هم یک کلاینت X و هم یک کارساز X است.
.B Xnest
کلاینتی برای کارساز واقعی است که پنجره‌ها و درخواست‌های گرافیکی را از جانب آن مدیریت می‌کند.
.B Xnest
برای کلاینت‌های خودش یک کارساز است.
.B Xnest
پنجره‌ها و درخواست‌های گرافیکی را از طرف آن‌ها مدیریت می‌کند.
برای این کلاینت‌ها،
.B Xnest
مانند یک کارساز متداول به نظر می‌رسد.
.SH "گزینه‌ها (OPTIONS)"
.B Xnest
از تمام گزینه‌های استاندارد پیاده‌سازی نمونهٔ کارساز پشتیبانی می‌کند.
برای جزئیات بیشتر، لطفاً
.BR Xserver (1)
را ببینید.
آرگومان‌های اضافی زیر نیز پشتیبانی می‌شوند.
.TP
.BI "\-display " string
این گزینه نام نمایشگر (display) کارساز واقعی را مشخص می‌کند که
.B Xnest
باید تلاش کند به آن متصل شود.
اگر در خط فرمان مشخص نشود،
.B Xnest
متغیر محیطی
.I DISPLAY
را به‌منظور یافتن این اطلاعات می‌خواند.
.TP
.B \-sync
این گزینه به
.B Xnest
می‌گوید که عملیات پنجره‌ها و گرافیک خود را با کارساز واقعی همگام‌سازی کند.
این گزینه برای اشکال‌زدایی مفید است، اما کارایی
.B Xnest
را به‌طور قابل توجهی کاهش می‌دهد.
نباید از آن استفاده شود مگر در موارد کاملاً ضروری.
.TP
.B \-full
این گزینه به
.B Xnest
می‌گوید که از بازسازی (regeneration) کامل اشیاء کارساز واقعی استفاده کند و هر بار که کارساز تودرتو بازسازی می‌شود، اتصال جدیدی را با کارساز واقعی باز کند.
پیاده‌سازی نمونهٔ کارساز زمانی که آخرین کلاینت این کارساز خاتمه می‌یابد، تمام اشیاء درون کارساز را بازسازی می‌کند.
وقتی این اتفاق می‌افتد،
.B Xnest
به‌طور پیش‌فرض همان پنجرهٔ سطح بالا (top-level) و همان اتصال کارساز واقعی را در هر بازسازی جدید حفظ می‌کند.
اگر کاربر بازسازی کامل را انتخاب کند، حتی پنجرهٔ سطح بالا و اتصال به کارساز واقعی نیز برای هر بار بازسازی کارساز از نو ساخته خواهند شد.
.TP
.BI "\-class " string
این گزینه کلاس دیداری (visual class) پیش‌فرض کارساز تودرتو را مشخص می‌کند.
این گزینه شبیه به گزینهٔ
.B \-cc
از مجموعه گزینه‌های استاندارد است، با این تفاوت که به‌جای یک عدد، یک رشته را برای مشخص کردن کلاس دیداری می‌پذیرد.
مقدار
.I string
باید یکی از شش مقدار زیر باشد:
.BR StaticGray "،"
.BR GrayScale "،"
.BR StaticColor "،"
.BR PseudoColor "،"
.BR TrueColor
یا
.BR DirectColor .
اگر هر دو گزینهٔ
.B \-class
و
.B \-cc
مشخص شده باشند، آخرین مورد مشخص‌شده از هر یک از گزینه‌ها اولویت دارد.
نیازی نیست کلاس دیداری پیش‌فرض کارساز تودرتو با کلاس دیداری پیش‌فرض کارساز واقعی یکسان باشد، اما باید توسط کارساز واقعی پشتیبانی شود.
پیش از اجرای
.BR Xnest ،
از
.BR xdpyinfo (1)
برای دریافت فهرستی از کلاس‌های دیداری پشتیبانی‌شده در کارساز واقعی استفاده کنید.
اگر کاربر یک کلاس ایستا (static) را انتخاب کند، تمام رنگ‌ها در جدول رنگ پیش‌فرض از پیش تخصیص می‌یابند.
اگر کاربر یک کلاس پویا (dynamic) را انتخاب کند، رنگ‌های موجود در جدول رنگ پیش‌فرض برای تخصیص توسط تک‌تک کلاینت‌ها در دسترس خواهند بود.
.TP
.BI "\-depth " int
این گزینه عمق دیداری پیش‌فرض کارساز تودرتو را مشخص می‌کند.
عمق دیداری پیش‌فرض کارساز تودرتو نیازی نیست با عمق دیداری پیش‌فرض کارساز واقعی یکسان باشد، اما باید توسط کارساز واقعی پشتیبانی شود.
پیش از شروع
.BR Xnest ،
از
.BR xdpyinfo (1)
برای به‌دست آوردن فهرستی از عمق‌های دیداری پشتیبانی‌شده در کارساز واقعی استفاده کنید.
.TP
.B \-sss
این گزینه به
.B Xnest
می‌گوید که از محافظ صفحهٔ (screen saver) نرم‌افزاری استفاده کند.
به‌طور پیش‌فرض،
.B Xnest
از محافظ صفحه‌ای استفاده می‌کند که با محافظ صفحهٔ سخت‌افزاری در کارساز واقعی مطابقت دارد.
البته از آنجا که
.B Xnest
هیچ سخت‌افزار واقعی را کنترل نمی‌کند، حتی این محافظ صفحه نیز به‌صورت نرم‌افزاری تولید می‌شود.
با این حال، در کد نمونهٔ کارساز به عنوان یک محافظ صفحهٔ سخت‌افزاری با آن رفتار می‌شود.
.TP
.B \-geometry \fIW\fBx\fIH\fB+\fIX\fB+\fIY\fP
این گزینه پارامترهای هندسه (ابعاد و موقعیت) را برای پنجرهٔ سطح بالای
.B Xnest
مشخص می‌کند.
برای بررسی ساختار این گزینه، بخش \(lqGEOMETRY SPECIFICATIONS\(rq را در
.BR X (7)
ببینید.
این پنجره متناظر با پنجرهٔ ریشه (root window) کارساز تودرتو است.
عرض
.I W
و ارتفاع
.I H
مشخص‌شده با این گزینه، حداکثر عرض و ارتفاع هر پنجرهٔ سطح بالای
.B Xnest
خواهد بود.
.B Xnest
به کاربر اجازه می‌دهد تا هر پنجرهٔ سطح بالا را کوچک‌تر کند، اما اندازهٔ پنجرهٔ ریشهٔ کارساز تودرتو را واقعاً تغییر نمی‌دهد.
.B Xnest
هنوز از افزونهٔ RANDR برای تغییر اندازه، چرخش و بازتاب پنجرهٔ ریشه پشتیبانی نمی‌کند.
اگر این گزینه مشخص نشود،
.B Xnest
مقادیر
.I W
و
.I H
را برابر با ۳/۴ ابعاد پنجرهٔ ریشهٔ کارساز واقعی قرار خواهد داد.
.TP
.BI "\-bw " int
این گزینه ضخامت حاشیهٔ پنجرهٔ سطح بالای
.B Xnest
را مشخص می‌کند.
پارامتر عددی صحیح
.I int
باید مثبت باشد.
ضخامت حاشیهٔ پیش‌فرض ۱ است.
.TP
.BI "\-name " string
این گزینه نام پنجرهٔ سطح بالای
.B Xnest
را به عنوان
.I string
تعیین می‌کند.
مقدار پیش‌فرض، نام برنامه است.
.TP
.BI "\-scrns " int
این گزینه تعداد صفحه‌هایی را که باید در کارساز تودرتو ایجاد شوند مشخص می‌کند.
برای هر صفحه،
.B Xnest
یک پنجرهٔ سطح بالای مجزا ایجاد خواهد کرد.
به هر صفحه با عددی که پس از نقطه در مشخصهٔ نام نمایشگر کلاینت می‌آید ارجاع داده می‌شود.
برای مثال،
.B xterm \-display :1.1
یک کلاینت
.BR xterm (1)
را در کارساز تودرتو با شمارهٔ نمایشگر
.B :1
روی صفحهٔ دوم باز خواهد کرد.
تعداد صفحه‌ها با یک مقدار ثابت کدنویسی‌شده در کد نمونهٔ کارساز محدود شده است که معمولاً ۳ می‌باشد..TP
.B \-install
این گزینه به
.B Xnest
می‌گوید که با دور زدن مدیر پنجرهٔ واقعی، نصب جدول رنگ (color map) خود را مستقیماً انجام دهد.
برای کارکرد درست آن، کاربر احتمالاً باید موقتاً از مدیر پنجرهٔ واقعی خارج شود.
به‌طور پیش‌فرض،
.B Xnest
پنجرهٔ کلاینت تودرتویی را که باید جدول رنگ آن روی کارساز واقعی نصب شود، در ویژگی
.I WM_COLORMAP_WINDOWS
پنجرهٔ سطح بالای
.B Xnest
نگه می‌دارد.
اگر این جدول رنگ از همان نوع دیداریِ (visual type) پنجرهٔ ریشهٔ کارساز تودرتو باشد،
.B Xnest
این جدول رنگ را به پنجرهٔ سطح بالای
.B Xnest
نیز مرتبط خواهد کرد.
از آنجا که لزوماً این‌گونه نیست، مدیرهای پنجره باید اساساً به ویژگی
.I WM_COLORMAP_WINDOWS
نگاه کنند، نه جدول رنگ مرتبط با پنجرهٔ سطح بالای
.BR Xnest .
.\" Is the following still true?  This sentence is several years old.
متأسفانه مدیرهای پنجره هنوز در انجام این کار چندان خوب عمل نمی‌کنند؛ بنابراین ممکن است این گزینه به کار آید.
.TP
.BI "\-parent " window_id
این گزینه به
.B Xnest
می‌گوید که به جای ایجاد یک پنجره، از
.I window_id
به عنوان پنجرهٔ ریشه استفاده کند.
.\" XRX is dead, dead, dead.
.\" This option is used by the xrx xnestplugin.
.SH "توضیحات تکمیلی (EXTENDED DESCRIPTION)"
راه‌اندازی
.B Xnest
دقیقاً به سادگی اجرای
.BR xclock (1)
از یک شبیه‌ساز پایانه است.
اگر کاربری بخواهد
.B Xnest
را روی همان ایستگاه کاریِ کارساز واقعی اجرا کند، مهم است که به کارساز تودرتو یک آدرس سوکت شنود اختصاصی داده شود.
بنابراین اگر از پیش کارسازی روی ایستگاه کاری کاربر در حال اجرا باشد،
.B Xnest
باید با یک شمارهٔ نمایشگر (display number) جدید راه‌اندازی شود.
از آنجا که معمولاً بیش از یک کارساز روی یک ایستگاه کاری اجرا نمی‌شود، مشخص کردن
.RB \(oq "Xnest :1" \(cq
در خط فرمان برای بیشتر کاربران کافی خواهد بود.
به ازای هر کارساز در حال اجرا روی ایستگاه کاری، شمارهٔ نمایشگر باید یک واحد افزایش یابد.
بنابراین اگر مایلید یک
.B Xnest
دیگر راه‌اندازی کنید، باید
.RB \(oq "Xnest :2" \(cq
را در خط فرمان وارد کنید.
.PP
برای اجرای کلاینت‌ها در کارساز تودرتو، باید به هر کلاینت همان شمارهٔ نمایشگرِ کارساز تودرتو داده شود.
برای نمونه،
.RB \(oq "xterm \-display :1" \(cq
یک فرایند
.B xterm
را در نخستین کارساز تودرتو راه‌اندازی می‌کند و
.RB \(oq "xterm \-display :2" \(cq
یک
.B xterm
را در دومین کارساز تودرتوی مثال بالا آغاز خواهد کرد.
کلاینت‌های دیگر را می‌توان از این
.BR xterm ها
در هر کارساز تودرتو راه‌اندازی کرد.
.SS "Xnest به عنوان یک کلاینت"
.B Xnest
در نگاه کارساز واقعی و دیگر کلاینت‌های واقعی، رفتار و ظاهری مانند یک کلاینت واقعیِ دیگر دارد.
با این وجود، کلاینتی نسبتاً پرتوقع و سنگین است؛ زیرا تقریباً هر درخواست پنجره یا گرافیکی از سوی کلاینت تودرتو، به یک درخواست پنجره یا گرافیک از سوی
.B Xnest
به کارساز واقعی تبدیل می‌شود.
از این رو، مطلوب است که
.B Xnest
و کارساز واقعی روی یک شبکهٔ محلی، یا حتی بهتر، روی همان ماشین باشند.
.B Xnest
فرض می‌کند که کارساز واقعی از افزونهٔ SHAPE پشتیبانی می‌کند.
هیچ راهی برای غیرفعال کردن پویای این پیش‌فرض وجود ندارد.
.B Xnest
می‌تواند بدون پشتیبانی داخلی از افزونهٔ SHAPE کامپایل شود که در این صورت نیازی به پشتیبانی کارساز واقعی از آن نیست.
پشتیبانی از انتخاب پویای افزونهٔ SHAPE ممکن است در توسعه‌های بعدی
.B Xnest
مد نظر قرار گیرد.
.PP
از آنجا که نیازی نیست
.B Xnest
از دیداریِ پیش‌فرض یکسانی با کارساز واقعی استفاده کند، پنجرهٔ سطح بالای کلاینت
.B Xnest
همواره جدول رنگ اختصاصی خود را دارد.
این بدان معناست که در زمان قرار داشتن تمرکز صفحه‌کلید یا اشاره‌گر درون پنجرهٔ
.BR Xnest ،
رنگ‌های دیگر پنجره‌ها به درستی نمایش داده نخواهند شد، مگر اینکه کارساز واقعی از نصب هم‌زمان بیش از یک جدول رنگ پشتیبانی کند.
جدول رنگ مرتبط با پنجرهٔ بالایی کلاینت
.B Xnest
لزوماً همان جدول رنگ مناسبی نیست که کارساز تودرتو می‌خواهد روی کارساز واقعی نصب شود.
در صورتی که یک کلاینت تودرتو تلاش کند جدول رنگی با دیداری متفاوت از دیداریِ پیش‌فرض کارساز تودرتو نصب کند،
.B Xnest
پنجرهٔ بالایی این کلاینت تودرتو و تمام پنجره‌های بالایی دیگر کلاینت‌های تودرتویی را که از همان جدول رنگ استفاده می‌کنند، درون ویژگی
.I WM_COLORMAP_WINDOWS
پنجرهٔ سطح بالای
.B Xnest
روی کارساز واقعی قرار خواهد داد.
بنابراین مهم است مدیر پنجرهٔ واقعی که پنجرهٔ سطح بالای
.B Xnest
را مدیریت می‌کند، به جای جدول رنگ مرتبط با پنجرهٔ سطح بالای
.BR Xnest ،
به ویژگی
.I WM_COLORMAP_WINDOWS
توجه کند.
از آنجا که به نظر می‌رسد هنوز بیشتر مدیرهای پنجره این قاعده را به درستی پیاده‌سازی نکرده‌اند،
.B Xnest
می‌تواند به‌صورت اختیاری و با دور زدن مدیر پنجرهٔ واقعی، جدول‌های رنگ را مستقیماً روی کارساز واقعی نصب کند.
اگر کاربر این گزینه را برگزیند، معمولاً لازم است مدیر پنجرهٔ واقعی موقتاً غیرفعال شود، چرا که با سازوکار نصب جدول رنگ
.B Xnest
تداخل پیدا خواهد کرد.
.PP
روال‌های کنترل صفحه‌کلید و اشاره‌گر در کارساز تودرتو، پارامترهای کنترل صفحه‌کلید و اشاره‌گرِ کارساز واقعی را تغییر می‌دهند.
بنابراین پس از آن‌که
.B Xnest
راه‌اندازی شد، کنترل‌های صفحه‌کلید و اشاره‌گر کارساز واقعی را به مقادیر پیش‌فرض داخلی خود تغییر می‌دهد..SS "Xnest به عنوان یک کارساز"
.B Xnest
به عنوان یک کارساز، برای کلاینت‌های خود دقیقاً مانند یک کارساز واقعی به نظر می‌رسد.
برای کلاینت‌ها، هیچ راهی برای تشخیص این‌که روی یک کارساز واقعی در حال اجرا هستند یا یک
کارساز تودرتو وجود ندارد.
.PP
همان‌طور که پیش‌تر اشاره شد،
.B Xnest
هنگام سفارشی‌سازی، کارسازی بسیار کاربرپسند است.
.B Xnest
تعدادی آرگومان خط فرمان را می‌پذیرد که می‌توانند کلاس بصری (visual class) و عمق پیش‌فرض آن، تعداد صفحه‌نمایش‌ها و موارد دیگر را پیکربندی کنند.
.PP
تنها پیچیدگی آشکار از دیدگاه کاربران دربارهٔ استفاده از
.B Xnest
به عنوان یک کارساز، انتخاب قلم‌ها است.
.B Xnest
قلم‌ها را با بارگذاری محلی آن‌ها و سپس ارسال نام قلم به کارساز واقعی و درخواست از آن برای بارگذاری آن قلم از راه دور، مدیریت می‌کند.
این رویکرد از بار اضافیِ ارسال بیت‌های گلیف در سراسر شبکه برای هر عملیات متنی جلوگیری می‌کند، هرچند که در واقع یک باگ به شمار می‌رود.
پیامد این رویکرد این است که کاربر باید نگران دو مسیر قلم متفاوت باشد \(em یکی محلی برای کارساز تودرتو و دیگری دوردست برای کارساز واقعی \(em چرا که
.B Xnest
مسیر قلم خود را به کارساز واقعی منتشر نمی‌کند.
دلیل این امر آن است که لزومی ندارد کارسازهای واقعی و تودرتو روی یک فایل‌سیستم مشترک اجرا شوند، که این مسئله باعث ناسازگاری متقابل این دو مسیر قلم می‌شود.
بنابراین، اگر قلمی در مسیر قلم محلیِ کارساز تودرتو وجود داشته باشد، هیچ تضمینی وجود ندارد که این قلم در مسیر قلم دوردستِ کارساز واقعی نیز موجود باشد.
کلاینت
.BR xlsfonts (1)
اگر روی کارساز تودرتو اجرا شود، قلم‌های موجود در مسیر قلم محلی را فهرست می‌کند و اگر روی کارساز واقعی اجرا شود، قلم‌های مسیر قلم دوردست را فهرست خواهد کرد.
پیش از آن‌که یک قلم بتواند با موفقیت توسط کارساز تودرتو باز شود، باید هم در مسیر قلم محلی و هم در مسیر دوردست وجود داشته باشد.
اطمینان از وجود این شرایط بر عهدهٔ کاربر است.
.SH "برنامه‌های آینده (FUTURE DIRECTIONS)"
پویاسازی نیازمندی به افزونهٔ SHAPE در کارساز واقعی، به جای نیاز به کامپایل مجدد
.B Xnest
برای فعال یا غیرفعال کردن این نیازمندی.
.PP
شاید بهتر باشد یک گزینهٔ خط فرمان وجود داشته باشد تا به
.B Xnest
اعلام کند پارامترهای کنترل صفحه‌کلید و اشاره‌گر را به جای اعمال پارامترهای خود، از کارساز واقعی به ارث ببرد.
.PP
.B Xnest
باید یک فایل ورودی سفارشی‌سازی را بخواند تا آزادی عمل و سادگی بیشتری در انتخاب چیدمان مد نظر فراهم کند.
.PP
هیچ پشتیبانی‌ای از backing store و save unders وجود ندارد، اما این مورد نیز باید در نظر گرفته شود.
.PP
.\" Is the following still true now that client-side font rendering is
.\" considered the way to go?
پیاده‌سازی مناسب قلم‌ها باید به لایهٔ
.I os
منتقل شود.
.SH "اشکالات (BUGS)"
روی کارسازهایی که از عمق‌های بصری متفاوت پشتیبانی می‌کنند به خوبی اجرا نمی‌شود.
.PP
همچنان به طور تصادفی کرش می‌کند.
.PP
احتمالاً دارای مقداری نشت حافظه است.
.SH "نویسنده (AUTHOR)"
Davor Matic, MIT X Consortium
.SH "همچنین ببینید (SEE ALSO)"
.BR Xserver (1),
.BR xdpyinfo (1),
.BR X (7)