Xnest(1) General Commands Manual Xnest(1)

Xnest - یک کارساز X تودرتو

Xnest [ گزینه‌ها ]

Xnest هم یک کلاینت X و هم یک کارساز X است. Xnest کلاینتی برای کارساز واقعی است که پنجره‌ها و درخواست‌های گرافیکی را از جانب آن مدیریت می‌کند. Xnest برای کلاینت‌های خودش یک کارساز است. Xnest پنجره‌ها و درخواست‌های گرافیکی را از طرف آن‌ها مدیریت می‌کند. برای این کلاینت‌ها، Xnest مانند یک کارساز متداول به نظر می‌رسد.

Xnest از تمام گزینه‌های استاندارد پیاده‌سازی نمونهٔ کارساز پشتیبانی می‌کند. برای جزئیات بیشتر، لطفاً Xserver(1) را ببینید. آرگومان‌های اضافی زیر نیز پشتیبانی می‌شوند.

این گزینه نام نمایشگر (display) کارساز واقعی را مشخص می‌کند که Xnest باید تلاش کند به آن متصل شود. اگر در خط فرمان مشخص نشود، Xnest متغیر محیطی DISPLAY را به‌منظور یافتن این اطلاعات می‌خواند.
این گزینه به Xnest می‌گوید که عملیات پنجره‌ها و گرافیک خود را با کارساز واقعی همگام‌سازی کند. این گزینه برای اشکال‌زدایی مفید است، اما کارایی Xnest را به‌طور قابل توجهی کاهش می‌دهد. نباید از آن استفاده شود مگر در موارد کاملاً ضروری.
این گزینه به Xnest می‌گوید که از بازسازی (regeneration) کامل اشیاء کارساز واقعی استفاده کند و هر بار که کارساز تودرتو بازسازی می‌شود، اتصال جدیدی را با کارساز واقعی باز کند. پیاده‌سازی نمونهٔ کارساز زمانی که آخرین کلاینت این کارساز خاتمه می‌یابد، تمام اشیاء درون کارساز را بازسازی می‌کند. وقتی این اتفاق می‌افتد، Xnest به‌طور پیش‌فرض همان پنجرهٔ سطح بالا (top-level) و همان اتصال کارساز واقعی را در هر بازسازی جدید حفظ می‌کند. اگر کاربر بازسازی کامل را انتخاب کند، حتی پنجرهٔ سطح بالا و اتصال به کارساز واقعی نیز برای هر بار بازسازی کارساز از نو ساخته خواهند شد.
این گزینه کلاس دیداری (visual class) پیش‌فرض کارساز تودرتو را مشخص می‌کند. این گزینه شبیه به گزینهٔ -cc از مجموعه گزینه‌های استاندارد است، با این تفاوت که به‌جای یک عدد، یک رشته را برای مشخص کردن کلاس دیداری می‌پذیرد. مقدار string باید یکی از شش مقدار زیر باشد: StaticGray، GrayScale، StaticColor، PseudoColor، TrueColor یا DirectColor. اگر هر دو گزینهٔ -class و -cc مشخص شده باشند، آخرین مورد مشخص‌شده از هر یک از گزینه‌ها اولویت دارد. نیازی نیست کلاس دیداری پیش‌فرض کارساز تودرتو با کلاس دیداری پیش‌فرض کارساز واقعی یکسان باشد، اما باید توسط کارساز واقعی پشتیبانی شود. پیش از اجرای Xnest، از xdpyinfo(1) برای دریافت فهرستی از کلاس‌های دیداری پشتیبانی‌شده در کارساز واقعی استفاده کنید. اگر کاربر یک کلاس ایستا (static) را انتخاب کند، تمام رنگ‌ها در جدول رنگ پیش‌فرض از پیش تخصیص می‌یابند. اگر کاربر یک کلاس پویا (dynamic) را انتخاب کند، رنگ‌های موجود در جدول رنگ پیش‌فرض برای تخصیص توسط تک‌تک کلاینت‌ها در دسترس خواهند بود.
این گزینه عمق دیداری پیش‌فرض کارساز تودرتو را مشخص می‌کند. عمق دیداری پیش‌فرض کارساز تودرتو نیازی نیست با عمق دیداری پیش‌فرض کارساز واقعی یکسان باشد، اما باید توسط کارساز واقعی پشتیبانی شود. پیش از شروع Xnest، از xdpyinfo(1) برای به‌دست آوردن فهرستی از عمق‌های دیداری پشتیبانی‌شده در کارساز واقعی استفاده کنید.
این گزینه به Xnest می‌گوید که از محافظ صفحهٔ (screen saver) نرم‌افزاری استفاده کند. به‌طور پیش‌فرض، Xnest از محافظ صفحه‌ای استفاده می‌کند که با محافظ صفحهٔ سخت‌افزاری در کارساز واقعی مطابقت دارد. البته از آنجا که Xnest هیچ سخت‌افزار واقعی را کنترل نمی‌کند، حتی این محافظ صفحه نیز به‌صورت نرم‌افزاری تولید می‌شود. با این حال، در کد نمونهٔ کارساز به عنوان یک محافظ صفحهٔ سخت‌افزاری با آن رفتار می‌شود.
این گزینه پارامترهای هندسه (ابعاد و موقعیت) را برای پنجرهٔ سطح بالای Xnest مشخص می‌کند. برای بررسی ساختار این گزینه، بخش “GEOMETRY SPECIFICATIONS” را در X(7) ببینید. این پنجره متناظر با پنجرهٔ ریشه (root window) کارساز تودرتو است. عرض W و ارتفاع H مشخص‌شده با این گزینه، حداکثر عرض و ارتفاع هر پنجرهٔ سطح بالای Xnest خواهد بود. Xnest به کاربر اجازه می‌دهد تا هر پنجرهٔ سطح بالا را کوچک‌تر کند، اما اندازهٔ پنجرهٔ ریشهٔ کارساز تودرتو را واقعاً تغییر نمی‌دهد. Xnest هنوز از افزونهٔ RANDR برای تغییر اندازه، چرخش و بازتاب پنجرهٔ ریشه پشتیبانی نمی‌کند. اگر این گزینه مشخص نشود، Xnest مقادیر W و H را برابر با ۳/۴ ابعاد پنجرهٔ ریشهٔ کارساز واقعی قرار خواهد داد.
این گزینه ضخامت حاشیهٔ پنجرهٔ سطح بالای Xnest را مشخص می‌کند. پارامتر عددی صحیح int باید مثبت باشد. ضخامت حاشیهٔ پیش‌فرض ۱ است.
این گزینه نام پنجرهٔ سطح بالای Xnest را به عنوان string تعیین می‌کند. مقدار پیش‌فرض، نام برنامه است.
این گزینه تعداد صفحه‌هایی را که باید در کارساز تودرتو ایجاد شوند مشخص می‌کند. برای هر صفحه، Xnest یک پنجرهٔ سطح بالای مجزا ایجاد خواهد کرد. به هر صفحه با عددی که پس از نقطه در مشخصهٔ نام نمایشگر کلاینت می‌آید ارجاع داده می‌شود. برای مثال، xterm -display :1.1 یک کلاینت xterm(1) را در کارساز تودرتو با شمارهٔ نمایشگر :1 روی صفحهٔ دوم باز خواهد کرد. تعداد صفحه‌ها با یک مقدار ثابت کدنویسی‌شده در کد نمونهٔ کارساز محدود شده است که معمولاً ۳ می‌باشد..TP -install این گزینه به Xnest می‌گوید که با دور زدن مدیر پنجرهٔ واقعی، نصب جدول رنگ (color map) خود را مستقیماً انجام دهد. برای کارکرد درست آن، کاربر احتمالاً باید موقتاً از مدیر پنجرهٔ واقعی خارج شود. به‌طور پیش‌فرض، Xnest پنجرهٔ کلاینت تودرتویی را که باید جدول رنگ آن روی کارساز واقعی نصب شود، در ویژگی WM_COLORMAP_WINDOWS پنجرهٔ سطح بالای Xnest نگه می‌دارد. اگر این جدول رنگ از همان نوع دیداریِ (visual type) پنجرهٔ ریشهٔ کارساز تودرتو باشد، Xnest این جدول رنگ را به پنجرهٔ سطح بالای Xnest نیز مرتبط خواهد کرد. از آنجا که لزوماً این‌گونه نیست، مدیرهای پنجره باید اساساً به ویژگی WM_COLORMAP_WINDOWS نگاه کنند، نه جدول رنگ مرتبط با پنجرهٔ سطح بالای Xnest. متأسفانه مدیرهای پنجره هنوز در انجام این کار چندان خوب عمل نمی‌کنند؛ بنابراین ممکن است این گزینه به کار آید.
این گزینه به Xnest می‌گوید که به جای ایجاد یک پنجره، از window_id به عنوان پنجرهٔ ریشه استفاده کند.

راه‌اندازی Xnest دقیقاً به سادگی اجرای xclock(1) از یک شبیه‌ساز پایانه است. اگر کاربری بخواهد Xnest را روی همان ایستگاه کاریِ کارساز واقعی اجرا کند، مهم است که به کارساز تودرتو یک آدرس سوکت شنود اختصاصی داده شود. بنابراین اگر از پیش کارسازی روی ایستگاه کاری کاربر در حال اجرا باشد، Xnest باید با یک شمارهٔ نمایشگر (display number) جدید راه‌اندازی شود. از آنجا که معمولاً بیش از یک کارساز روی یک ایستگاه کاری اجرا نمی‌شود، مشخص کردن ‘Xnest :1’ در خط فرمان برای بیشتر کاربران کافی خواهد بود. به ازای هر کارساز در حال اجرا روی ایستگاه کاری، شمارهٔ نمایشگر باید یک واحد افزایش یابد. بنابراین اگر مایلید یک Xnest دیگر راه‌اندازی کنید، باید ‘Xnest :2’ را در خط فرمان وارد کنید.

برای اجرای کلاینت‌ها در کارساز تودرتو، باید به هر کلاینت همان شمارهٔ نمایشگرِ کارساز تودرتو داده شود. برای نمونه، ‘xterm -display :1’ یک فرایند xterm را در نخستین کارساز تودرتو راه‌اندازی می‌کند و ‘xterm -display :2’ یک xterm را در دومین کارساز تودرتوی مثال بالا آغاز خواهد کرد. کلاینت‌های دیگر را می‌توان از این xtermها در هر کارساز تودرتو راه‌اندازی کرد.

Xnest در نگاه کارساز واقعی و دیگر کلاینت‌های واقعی، رفتار و ظاهری مانند یک کلاینت واقعیِ دیگر دارد. با این وجود، کلاینتی نسبتاً پرتوقع و سنگین است؛ زیرا تقریباً هر درخواست پنجره یا گرافیکی از سوی کلاینت تودرتو، به یک درخواست پنجره یا گرافیک از سوی Xnest به کارساز واقعی تبدیل می‌شود. از این رو، مطلوب است که Xnest و کارساز واقعی روی یک شبکهٔ محلی، یا حتی بهتر، روی همان ماشین باشند. Xnest فرض می‌کند که کارساز واقعی از افزونهٔ SHAPE پشتیبانی می‌کند. هیچ راهی برای غیرفعال کردن پویای این پیش‌فرض وجود ندارد. Xnest می‌تواند بدون پشتیبانی داخلی از افزونهٔ SHAPE کامپایل شود که در این صورت نیازی به پشتیبانی کارساز واقعی از آن نیست. پشتیبانی از انتخاب پویای افزونهٔ SHAPE ممکن است در توسعه‌های بعدی Xnest مد نظر قرار گیرد.

از آنجا که نیازی نیست Xnest از دیداریِ پیش‌فرض یکسانی با کارساز واقعی استفاده کند، پنجرهٔ سطح بالای کلاینت Xnest همواره جدول رنگ اختصاصی خود را دارد. این بدان معناست که در زمان قرار داشتن تمرکز صفحه‌کلید یا اشاره‌گر درون پنجرهٔ Xnest، رنگ‌های دیگر پنجره‌ها به درستی نمایش داده نخواهند شد، مگر اینکه کارساز واقعی از نصب هم‌زمان بیش از یک جدول رنگ پشتیبانی کند. جدول رنگ مرتبط با پنجرهٔ بالایی کلاینت Xnest لزوماً همان جدول رنگ مناسبی نیست که کارساز تودرتو می‌خواهد روی کارساز واقعی نصب شود. در صورتی که یک کلاینت تودرتو تلاش کند جدول رنگی با دیداری متفاوت از دیداریِ پیش‌فرض کارساز تودرتو نصب کند، Xnest پنجرهٔ بالایی این کلاینت تودرتو و تمام پنجره‌های بالایی دیگر کلاینت‌های تودرتویی را که از همان جدول رنگ استفاده می‌کنند، درون ویژگی WM_COLORMAP_WINDOWS پنجرهٔ سطح بالای Xnest روی کارساز واقعی قرار خواهد داد. بنابراین مهم است مدیر پنجرهٔ واقعی که پنجرهٔ سطح بالای Xnest را مدیریت می‌کند، به جای جدول رنگ مرتبط با پنجرهٔ سطح بالای Xnest، به ویژگی WM_COLORMAP_WINDOWS توجه کند. از آنجا که به نظر می‌رسد هنوز بیشتر مدیرهای پنجره این قاعده را به درستی پیاده‌سازی نکرده‌اند، Xnest می‌تواند به‌صورت اختیاری و با دور زدن مدیر پنجرهٔ واقعی، جدول‌های رنگ را مستقیماً روی کارساز واقعی نصب کند. اگر کاربر این گزینه را برگزیند، معمولاً لازم است مدیر پنجرهٔ واقعی موقتاً غیرفعال شود، چرا که با سازوکار نصب جدول رنگ Xnest تداخل پیدا خواهد کرد.

روال‌های کنترل صفحه‌کلید و اشاره‌گر در کارساز تودرتو، پارامترهای کنترل صفحه‌کلید و اشاره‌گرِ کارساز واقعی را تغییر می‌دهند. بنابراین پس از آن‌که Xnest راه‌اندازی شد، کنترل‌های صفحه‌کلید و اشاره‌گر کارساز واقعی را به مقادیر پیش‌فرض داخلی خود تغییر می‌دهد..SS "Xnest به عنوان یک کارساز" Xnest به عنوان یک کارساز، برای کلاینت‌های خود دقیقاً مانند یک کارساز واقعی به نظر می‌رسد. برای کلاینت‌ها، هیچ راهی برای تشخیص این‌که روی یک کارساز واقعی در حال اجرا هستند یا یک کارساز تودرتو وجود ندارد.

همان‌طور که پیش‌تر اشاره شد، Xnest هنگام سفارشی‌سازی، کارسازی بسیار کاربرپسند است. Xnest تعدادی آرگومان خط فرمان را می‌پذیرد که می‌توانند کلاس بصری (visual class) و عمق پیش‌فرض آن، تعداد صفحه‌نمایش‌ها و موارد دیگر را پیکربندی کنند.

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

پویاسازی نیازمندی به افزونهٔ SHAPE در کارساز واقعی، به جای نیاز به کامپایل مجدد Xnest برای فعال یا غیرفعال کردن این نیازمندی.

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

Xnest باید یک فایل ورودی سفارشی‌سازی را بخواند تا آزادی عمل و سادگی بیشتری در انتخاب چیدمان مد نظر فراهم کند.

هیچ پشتیبانی‌ای از backing store و save unders وجود ندارد، اما این مورد نیز باید در نظر گرفته شود.

پیاده‌سازی مناسب قلم‌ها باید به لایهٔ os منتقل شود.

روی کارسازهایی که از عمق‌های بصری متفاوت پشتیبانی می‌کنند به خوبی اجرا نمی‌شود.

همچنان به طور تصادفی کرش می‌کند.

احتمالاً دارای مقداری نشت حافظه است.

Davor Matic, MIT X Consortium

Xserver(1), xdpyinfo(1), X(7)

xorg-server 21.1.24 X Version 11