• XDG_CONFIG_HOME/foot/foot.ini (در صورت عدم تنظیم، به صورت پیش‌فرض $HOME/.config/foot/foot.ini)
• XDG_CONFIG_DIRS/foot/foot.ini (در صورت عدم تنظیم، به صورت پیش‌فرض /etc/xdg/foot/foot.ini)

مثال‌ها:

توجه داشته باشید که بسته به تنظیمات شما، ممکن است گزینه‌های سراسری FontConfig وجود داشته باشند که گزینه‌های تنظیم‌شده در اینجا را بازنویسی کنند. اگر به نظر می‌رسد گزینه‌ای بی‌اثر است، اطمینان حاصل کنید پرونده پیکربندی سراسری وجود نداشته باشد که همان گزینه را با assign یا assign_replace تنظیم کند؛ از یکی از حالت‌های متعدد append یا احتمالاً prepend استفاده کنید.

برای هر گزینه، قلم نخست همان قلم اصلی است. قلم‌های باقی‌مانده قلم‌های جایگزین (fallback) هستند که هرگاه گلیفی در قلم اصلی یافت نشود استفاده خواهند شد.

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

گزینه‌های font-bold، font-italic و font-bold-italic امکان استفاده از قلم‌های سفارشی را برای قلم‌های پررنگ/مورب/پررنگ+مورب فراهم می‌کنند. در صورت عدم پیکربندی، گونه‌های پررنگ/مورب قلم (یا قلم‌های) عادی مشخص‌شده در font استفاده می‌شوند. نکته: ممکن است لازم باشد اندازه قلم‌های سفارشی پررنگ/مورب را طوری تنظیم کنید که با قلم عادی هماهنگ شوند.

برای غیرفعال کردن قلم‌های پررنگ و/یا مورب، مثلاً font-bold را دقیقاً روی همان مقدار font تنظیم کنید.

مقدار size بر حسب پوینت است (همان‌طور که در قالب FontConfig تعریف شده است). برای تنظیم اندازه بر حسب پیکسل، به جای آن از pixelsize استفاده کنید. توجه داشته باشید که اندازه‌های پیکسلی تحت تأثیر رندر آگاه از DPI نیستند (به dpi-aware مراجعه کنید)، اما تحت تأثیر مقیاس‌بندی میزکار قرار می‌گیرند.

پیش‌فرض: monospace:size=8 (font)، not set (font-bold، font-italic، font-bold-italic).

مثال‌ها:

font-size-adjustment=0.5   # تنظیم به اندازه ۰٫۵ پوینت
font-size-adjustment=10px  # تنظیم به اندازه ۱۰ پیکسل
font-size-adjustment=7.5%  # تنظیم به اندازه ۷٫۵ درصد

پیش‌فرض: 0.5

پرونده واردشده دامنه بخش مستقل خود را دارد. یعنی پیکربندی شامل‌کننده پس از include همچنان در بخش پیش‌فرض می‌ماند، صرف‌نظر از این‌که پرونده واردشده در چه بخشی به پایان برسد.

پیش‌فرض: not set.

می‌توانید با استفاده از پسوند px ارتفاعی بر حسب پیکسل مشخص کنید: برای نمونه line-height=12px.

هشدار: هنگام تغییر اندازه قلم در زمان اجرا (یعنی بزرگ‌نمایی یا کوچک‌نمایی)، foot ارتفاع سطر را با همان درصد تغییر می‌دهد. با این حال، به دلیل گرد کردن، این احتمال وجود دارد که ارتفاع سطر برای برخی اندازه‌های قلم «بیش از حد کوچک» شود و باعث «ناپدید شدن» مثلاً خطوط زیرین (underscores) گردد.

همچنین ببینید: vertical-letter-offset.

پیش‌فرض: not set.

می‌توانید با استفاده از پسوند px فاصله حروف را بر حسب پیکسل مشخص کنید: برای نمونه letter-spacing=2px.

همچنین ببینید: horizontal-letter-offset.

پیش‌فرض: 0.

برای تعیین آفست بر حسب پیکسل، پسوند px را اضافه کنید: برای نمونه horizontal-letter-offset=2px.

پیش‌فرض: 0.

برای مشخص کردن آفست بر حسب پیکسل، پسوند px را اضافه کنید: underline-offset=2px.

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

پیش‌فرض: unset.

برای مشخص کردن ضخامت بر حسب پیکسل، پسوند px را اضافه کنید: underline-thickness=1px.

در صورت عدم تنظیم (حالت پیش‌فرض)، از ضخامت مشخص‌شده در قلم استفاده می‌شود.

پیش‌فرض: unset

برای مشخص کردن ضخامت بر حسب پیکسل، پسوند px را اضافه کنید: strikeout-thickness=1px.

در صورت عدم تنظیم (حالت پیش‌فرض)، از ضخامت مشخص‌شده در قلم استفاده می‌شود.

پیش‌فرض: unset

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

کتابخانه FreeType می‌تواند با تکنیکی به نام تیره کردن ساقه (stem darkening) تأثیر دومی را محدود کند. این قابلیت فقط برای قلم‌های CFF (مانند OpenType، ‪.otf‬) در دسترس است و به طور پیش‌فرض (در FreeType) غیرفعال است. می‌توانید با تنظیم متغیر محیطی FREETYPE_PROPERTIES="cff:no-stem-darkening=0" پیش از راه‌اندازی foot آن را فعال کنید.

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

به منظور نمایش صادقانه رنگ‌ها، به بافرهای تصویری با دقت بالاتر نیاز است. به طور پیش‌فرض، foot در صورت فعال بودن ترکیب تصحیح‌شده با گاما، بسته به در دسترس بودن، از کانال‌های رنگی ۱۶ بیتی یا ۱۰ بیتی استفاده خواهد کرد. با این حال، بافرهای با دقت بالا کُند هستند؛ اگر می‌خواهید از ترکیب تصحیح‌شده با گاما استفاده کنید اما سرعت (توان پردازش و تاخیر ورودی) را به رنگ‌های دقیق ترجیح می‌دهید، می‌توانید با تنظیم tweak.surface-bit-depth=8-bit کانال‌های رنگی ۸ بیتی را اجباری کنید.

پیش‌فرض: no.

پیش‌فرض: yes

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

در صورت غیرفعال بودن، foot کدهای یونیکد زیر را خودش رندر می‌کند:

پیش‌فرض: no.

هنگامی که روی yes تنظیم شود، اندازه قلم‌ها با استفاده از DPI نمایشگر تعیین می‌شود، به طوری که قلمی با اندازه مشخص، بدون در نظر گرفتن نمایشگر، اندازه فیزیکی یکسانی خواهد داشت. به عبارت دیگر، اگر یک پنجره foot را بین نمایشگرهای مختلف بکشید، اندازه قلم یکسان باقی می‌ماند.

در این حالت، ضریب مقیاس‌بندی (scaling factor) نمایشگر نادیده گرفته می‌شود؛ دو برابر کردن ضریب مقیاس‌بندی اندازه قلم را دو برابر نخواهد کرد.

هنگامی که روی no تنظیم شود، DPI نمایشگر نادیده گرفته می‌شود. در عوض اندازه قلم با استفاده از ضریب مقیاس‌بندی نمایشگر تعیین می‌شود؛ دو برابر کردن ضریب مقیاس‌بندی اندازه قلم را دو برابر می‌کند.

توجه داشته باشید که این گزینه معمولاً با قلم‌های بیت‌مپ (bitmap) که فقط شامل مجموعه‌ای از اندازه‌های از پیش تعریف‌شده هستند و نمی‌توانند به صورت پویا مقیاس‌بندی شوند، کار نمی‌کند. هر اندازه‌ای (از اندازه‌های موجود) که بهترین تطابق را با DPI یا ضریب مقیاس‌بندی داشته باشد، استفاده خواهد شد.

همچنین توجه داشته باشید که اگر اندازه قلم بر حسب پیکسل مشخص شده باشد (:pixelsize=N به جای :size=N)، مقیاس‌بندی DPI (dpi-aware=yes) هیچ تأثیری نخواهد داشت (اندازه پیکسلی مشخص‌شده همان‌طور که هست استفاده می‌شود). اما اگر از ضریب مقیاس‌بندی نمایشگر برای تعیین اندازه قلم استفاده شود (dpi-aware=no)، اندازه پیکسلی قلم در ضریب مقیاس‌بندی ضرب خواهد شد.

پیش‌فرض: no

_XxY_ [center | center-when-fullscreen | center-when-maximized-and-fullscreen]

RIGHTxTOPxLEFTxBOTTOM [center | center-when-fullscreen | center-when-maximized-and-fullscreen]

•

`XxY` دست‌کم مقادیر زیر را می‌افزاید: - X پیکسل در سمت‌های چپ و راست. - Y پیکسل در سمت‌های بالا و پایین.

•

`LEFTxTOPxRIGHTxBOTTOM` دست‌کم مقادیر زیر را می‌افزاید: - LEFT پیکسل به چپ - TOP پیکسل به بالا - RIGHT پیکسل به راست - BOTTOM پیکسل به پایین

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

اگر center مشخص شود، محتوای شبکه در مرکز قرار می‌گیرد. این ممکن است هنگام تغییر اندازه پنجره باعث «پرش» شود.

با center-when-fullscreen و center-when-maximized-and-fullscreen، محتوای شبکه به گوشه بالا سمت چپ مهار می‌شود، مگر این‌که پنجره بیشینه (maximized) یا تمام‌صفحه شده باشد.

پیش‌فرض: 0x0 center-when-maximized-and-fullscreen.

به عبارت دیگر، در حالی که در حال دستکاری اندازه پنجره هستید، foot ابعاد به‌روزشده را به کلاینت ارسال نمی‌کند. همچنین به جای بازآرایی واقعی محتوا، یک تغییر اندازه «برش‌دهنده» سریع روی شبکه انجام می‌دهد. فقط زمانی که دستکاری را به مدت resize-delay-ms میلی‌ثانیه متوقف کنید، کلاینت به‌روز شده و محتوا به درستی بازآرایی می‌شود.

در اینجا تأکید بر حین است؛ به محض پایان تغییر اندازه تعاملی (یعنی زمانی که حاشیه پنجره را رها می‌کنید)، ابعاد نهایی بدون هیچ تاخیری به کلاینت ارسال می‌شود.

تنظیم آن روی 0 تاخیر را به طور کامل غیرفعال می‌کند.

پیش‌فرض: 100.

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

این گزینه فقط برای پنجره‌های شناور (floating) اعمال می‌شود. اندازه پنجره‌های بیشینه‌شده، کاشی‌شده (tiled) یا تمام‌صفحه به مضرب‌های اندازه سلول محدود نخواهد شد.

پیش‌فرض: yes

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

این گزینه فقط برای پنجره‌های شناور اعمال می‌شود.

پیش‌فرض: yes

مقدار dark از رنگ‌های تعریف‌شده در بخش colors-dark استفاده می‌کند، در حالی که light از رنگ‌های بخش colors-light بهره می‌برد.

از کلیدهای میانبر color-theme-switch-dark، color-theme-switch-light و color-theme-toggle برای جابجایی بین دو پوسته در زمان اجرا استفاده کنید، یا سیگنال‌های SIGUSR1/SIGUSR2 را به فرآیند foot بفرستید (برای جزئیات به foot(1) مراجعه کنید).

پیش‌فرض: dark

توجه داشته باشید که در صورت استفاده از مقیاس‌بندی کسری (fractional scaling)، ممکن است این گزینه مطابق انتظار کار نکند، به دلیل این واقعیت که بسیاری از کامپوزیتورها ضریب مقیاس‌بندی صحیح را تا پس از نگاشت پنجره گزارش نمی‌دهند.

پیش‌فرض: 700x500.

توجه داشته باشید که اگر از پیکربندی چند نمایشگر با ضرایب مقیاس‌بندی متفاوت استفاده می‌کنید، این احتمال وجود دارد که اندازه پنجره به درستی تنظیم نشود. در این صورت، به جای آن از initial-window-size-pixels استفاده کنید.

و درست مانند initial-window-size-pixels، در صورت استفاده از مقیاس‌بندی کسری ممکن است این گزینه مطابق انتظار عمل نکند (برای جزئیات به initial-window-size-pixels مراجعه کنید).

پیش‌فرض: not set.

اگر به جای یک yes|true ساده روی palette-based تنظیم شود، رنگ‌هایی که با یکی از ۸ رنگ پالت معمولی تطابق دارند، با استفاده از رنگ پالت روشن متناظر روشن‌تر می‌شوند. سایر رنگ‌ها روشن‌تر نخواهند شد.

پیش‌فرض: no.

در صورتی که تعداد بسیار زیادی هسته و/یا ریسمان دارید، محدود کردن تعداد workers را مد نظر قرار دهید، زیرا foot نمی‌تواند بیش از تعداد سطرهای قابل مشاهده را موازی‌سازی کند.

هنگام راه‌اندازی foot، با اجرای باینری کمکی به همراه آرگومان‌های زیر، یک رکورد utmp ایجاد می‌شود:

add $WAYLAND_DISPLAY

هنگام بسته شدن foot، با اجرای باینری کمکی به همراه آرگومان‌های زیر، رکورد utmp حذف می‌شود:

del

برای غیرفعال کردن رکوردهای utmp روی none تنظیم کنید. پیش‌فرض: /usr/lib/utempter/utempter.

قابلیت OSC-52 به برنامه ترمینال دسترسی به بریده‌دان میزبان (یعنی بریده‌دان Wayland) را می‌دهد. این مورد معمولاً یک مشکل امنیتی نیست، زیرا تمام برنامه‌ها می‌توانند مستقیماً از طریق سوکت Wayland به بریده‌دان دسترسی داشته باشند.

با این حال، هنگام اتصال با SSH به یک سیستم دوردست، یا دسترسی به یک کانتینر و غیره، برنامه‌های ترمینال ممکن است غیرقابل اعتماد باشند و شاید بخواهید دسترسی به بریده‌دان میزبان را غیرفعال کنید.

• disabled: تمام دسترسی‌ها به بریده‌دان را غیرفعال می‌کند
• copy-enabled: برنامه‌ها می‌توانند روی بریده‌دان بنویسند، اما نمی‌توانند از آن بخوانند.
• paste-enabled: برنامه‌ها می‌توانند از بریده‌دان بخوانند، اما نمی‌توانند روی آن بنویسند.
• enabled: تمام برنامه‌ها دسترسی کامل به بریده‌دان میزبان دارند. این حالت پیش‌فرض است.

پیش‌فرض: enabled

پیش‌فرض: yes

اگر کامپوزیتور این پروتکل را پیاده‌سازی نکرده باشد، حاشیه‌ها به رنگ قرمز نمایش داده خواهند شد.

برنامه‌ها می‌توانند این ویژگی را به صورت برنامه‌نویسی‌شده با توالی‌های گریز CSI ? 1042 h و CSI ? 1042 l فعال/غیرفعال کنند.

پیش‌فرض: no

پیش‌فرض: no

آرگومان‌های الگو

راه‌های راه‌اندازی اعلان‌ها

فعال‌سازی پنجره (فوکوس کردن)

خروجی استاندارد (Stdout)

پیش‌فرض: notify-send
--wait
--app-name ${app-id}
--icon ${app-id}
--category ${category}
--urgency ${urgency}
--expire-time ${expire-time}
--hint STRING:image-path:${icon}
--hint BOOLEAN:suppress-sound:${muted}
--hint STRING:sound-name:${sound-name}
--replace-id ${replace-id}
${action-argument}
--print-id
-- ${title} ${body}.

جایگزین: نمونه پیکربندی fyi: fyi
--wait
--app-name ${app-id}
--icon ${app-id}
--category ${category}
--urgency ${urgency}
--expire-time ${expire-time}
--hint string:image-path:${icon}
--hint boolean:suppress-sound:${muted}
--hint string:sound-name:${sound-name}
--replaces ${replace-id}
${action-argument}
--print-token
-- ${title} ${body}.

foot همیشه یک اقدام «پیش‌فرض» (default) را پیکربندی می‌کند که می‌تواند برای «فعال‌سازی» اعلان استفاده شود، که به نوبه خود می‌تواند باعث فوکوس پنجره foot شود یا یک توالی گریز به برنامه ترمینال ارسال کند (بسته به این‌که برنامه چگونه اعلان را تولید کرده است).

علاوه بر این، پروتکل اعلان‌های OSC-99 به برنامه‌ها اجازه می‌دهد تا اقدامات سفارشی خود را تعریف کنند. foot از ترکیبی از گزینه command و گزینه command-action-argument برای ارسال نام‌های اقدامات به برنامه کمکی اعلان استفاده می‌کند.

این گزینه دارای آرگومان‌های الگوی زیر است:

• ${action-name}: نام اقدام؛ default برای اقدام پیش‌فرض پیکربندی‌شده توسط foot، و n که در آن n یک عدد صحیح ۱ =< است برای اقدامات تعریف‌شده توسط برنامه.
• ${action-label}: مقدار Activate برای اقدام پیش‌فرض، و یک رشته آزاد برای اقدامات تعریف‌شده توسط برنامه.

به ازای هر اقدام اعلان (به یاد داشته باشید، همیشه دست‌کم یک اقدام وجود خواهد داشت)، گزینه command-action-argument با نام و برچسب آن اقدام بسط داده می‌شود.

سپس، ${action-argument} در دستور command به فهرست کامل اقدامات بسط می‌یابد.

اگر command-action-argument روی یک رشته خالی تنظیم شود، هیچ اقدامی به command ارسال نخواهد شد. یعنی ${action-argument} با یک رشته خالی جایگزین می‌شود.

مثال:

command-action-argument=--action ${action-name}=${action-label}
command=notify-send ${action-argument} ...

فرض کنید برنامه دو اقدام سفارشی تعریف کرده است: OK و Cancel.

با توجه به موارد فوق، foot دستور زیر را اجرا خواهد کرد:

پیش‌فرض: --action ${action-name}=${action-label}

${id} به شناسه اعلانی که باید بسته شود بسط می‌یابد. برای مثال:

بستن اعلان تنها توسط پروتکل اعلان‌های میزکار کیتی (Kitty Desktop Notification)، OSC-99 پشتیبانی می‌شود.

اگر روی رشته خالی تنظیم شود (حالت پیش‌فرض)، foot در عوض تلاش می‌کند تا با ارسال سیگنال SIGINT به فرآیند کمکی اعلان، آن را ببندد. برای مثال، دستور notify-send --wait (در libnotify >= 0.8.0) با بستن اعلان به SIGINT پاسخ می‌دهد.

پیش‌فرض: not set

پیش‌فرض: yes

هنگامی که روی url-mode تنظیم شود، نشانی‌های OSC-8 درست مانند نشانی‌های به طور خودکار شناسایی‌شده، فقط در حالت URL برجسته می‌شوند.

هنگامی که روی always تنظیم شود، نشانی‌های OSC-8 همیشه بدون در نظر گرفتن سایر ویژگی‌هایشان (پررنگ، مورب و غیره) برجسته می‌شوند. توجه داشته باشید که این کار آن‌ها را قابل کلیک نمی‌کند.

پیش‌فرض: url-mode

پیش‌فرض: dotted

اگر این گزینه را طوری تغییر دهید که شامل حرف t باشد، باید کلید میانبر پیش‌فرض [url-bindings].toggle-url-visible را نیز تغییر دهید تا از تداخل جلوگیری شود.

پیش‌فرض: sadfjklewcmpgh.

پیش‌فرض: (((https?://|mailto:|ftp://|file:|ssh:|ssh://|git://|tel:|magnet:|ipfs://|ipns://|gemini://|gopher://|news:)|www.)([0-9a-zA-Z:/?#@!$&*+,;=.~_%^'-]+|([]["0-9a-zA-Z:/?#@!$&'*+,;=.~_%^-]+)|[[()"0-9a-zA-Z:/?#@!$&'*+,;=.~_%^-]+]|"[][()0-9a-zA-Z:/?#@!$&'*+,;=.~_%^-]+"|'[][()0-9a-zA-Z:/?#@!$&*+,;=.~_%^-]+')+([0-9a-zA-Z/#@$&*+=~_%^-]|([]["0-9a-zA-Z:/?#@!$&'*+,;=.~_%^-]+)|[[()"0-9a-zA-Z:/?#@!$&'*+,;=.~_%^-]+]|"[][()0-9a-zA-Z:/?#@!$&'*+,;=.~_%^-]+"|'[][()0-9a-zA-Z:/?#@!$&*+,;=.~_%^-]+'))

[regex:hashes]
regex=([a-fA-F0-9]{7,128})
launch=path-to-script-or-application ${match}
[key-bindings]
regex-launch=[hashes] Control+Shift+q
regex-copy=[hashes] Control+Mod1+Shift+q

پیش‌فرض: not set.

• unchanged: رندر مکان‌نما دقیقاً به همان روشی که پنجره دارای فوکوس است.
• hollow: رندر مکان‌نمای بلوکی، اما به صورت توخالی.
• none: اصلاً هیچ مکان‌نمایی نمایش داده نشود.

برای مشخص کردن ضخامت بر حسب پیکسل، از پسوند px استفاده کنید: برای مثال underline-thickness=2px.

توجه داشته باشید که در صورت عدم تنظیم، ضخامت مکان‌نما با اندازه قلم مقیاس‌بندی می‌شود، در حالی که در صورت تنظیم، اندازه ثابت خواهد بود.

پیش‌فرض: font underline thickness.

این به شما امکان می‌دهد با موش‌واره در مثلاً صفحه‌بندها (مانند less) بدون فعال‌سازی پشتیبانی بومی موش‌واره در آن‌ها پیمایش کنید.

اگر برنامه پشتیبانی بومی موش‌واره را فعال کند، پیمایش جایگزین استفاده نمی‌شود.

این گزینه می‌تواند توسط برنامه‌ها در زمان اجرا با استفاده از توالی‌های گریز CSI ? 1007 h (فعال) و CSI ? 1007 l (غیرفعال) تغییر کند.

پیش‌فرض: yes.

پیش‌فرض: 400.

مثال: ff0000 00ff00 (مکان‌نمای سبز، متن قرمز)

پیش‌فرض: رنگ‌های پیش‌زمینه و پس‌زمینه عادی، معکوس‌شده.

به طور پیش‌فرض، foot این ویژگی را با ترکیب رنگ جاری با سیاه یا سفید، بسته به این‌که گزینه dim-blend-towards روی چه مقداری تنظیم شده باشد، پیاده‌سازی می‌کند. این یک رویکرد کلی است که هم برای رنگ‌های پالت ۲۵۶ رنگی و هم برای رنگ‌های ۲۴ بیتی RGB اعمال می‌شود.

می‌توانید با تنظیم گزینه‌های dimN این رفتار را تغییر دهید. در صورت تنظیم، foot رنگ جاری را با پالت رنگ مطابقت می‌دهد، و اگر با یکی از رنگ‌های regularN مطابقت داشته باشد، رنگ متناظر dimN استفاده خواهد شد.

اگر در عوض رنگ جاری با یکی از رنگ‌های brightN مطابقت داشته باشد، رنگ متناظر regularN استفاده خواهد شد.

اگر رنگ جاری با هیچ رنگ شناخته‌شده‌ای مطابقت نداشته باشد، با ترکیب با سیاه کم‌رنگ می‌شود (یعنی همان رفتاری که در صورت عدم پیکربندی گزینه‌های dimN رخ می‌دهد). رنگ‌های ۲۴ بیتی RGB معمولاً در این دسته قرار می‌گیرند.

توجه داشته باشید که برنامه‌ها می‌توانند رنگ‌های regularN و brightN را در زمان اجرا تغییر دهند. با این حال، راهی برای تغییر رنگ‌های dimN ندارند. اگر برنامه‌ای رنگ‌های regularN را تغییر داده باشد، foot همچنان از رنگ dimN متناظر، همان‌طور که در foot.ini پیکربندی شده، استفاده خواهد کرد.

پیش‌فرض: not set.

مقدار default شفافیت alpha را روی سلول‌هایی با رنگ پس‌زمینه پیش‌فرض اعمال می‌کند، به استثنای سلول‌هایی که دارای مقدار RGB یکسان با رنگ پس‌زمینه پیش‌فرض هستند.

مقدار matching مانند default است، اما alpha را روی سلول‌هایی با مقدار RGB یکسان با رنگ پس‌زمینه پیش‌فرض نیز اعمال می‌کند.

مقدار all شفافیت alpha را بدون در نظر گرفتن رنگ پس‌زمینه، روی تمام سلول‌ها اعمال می‌نماید.

پیش‌فرض: default

پیش‌فرض: no

پیش‌فرض: black (colors-dark)، white (colors-light)

توجه داشته باشید که این مورد تنها یک پیشنهاد به کامپوزیتور است. بسته به پشتیبانی کامپوزیتور و نحوه پیکربندی آن، ممکن است به foot دستور دهد از CSD استفاده کند حتی اگر این گزینه روی server تنظیم شده باشد، یا با وجود تنظیم client یا none، تزئینات SSD را رندر کند.

پیش‌فرض: server.

تا زمانی که رشته‌های دستور متفاوت باشند و کلیدهای میانبر منحصربه‌فرد باشند، می‌توانید چندین پایپ پیکربندی کنید.

توجه داشته باشید که دستور به طور خودکار درون یک پوسته اجرا نمی‌شود؛ در صورت نیاز به آن، از sh -c "command line" استفاده کنید.

مثال شماره ۱:

مثال شماره ۲:

پیش‌فرض: none

نام بخش regex باید در کلید میانبر مشخص شود:

[regex:hashes]
regex=([a-fA-F0-9]{7,128})
launch=path-to-script-or-application ${match}
[key-bindings]
regex-launch=[hashes] Control+Shift+q
regex-copy=[hashes] Control+Mod1+Shift+q

پیش‌فرض: none.

برای نمونه، جهت درج نویسه ö (حرف کوچک O لاتین با دونقطه، کدپوینت یونیکد 0xf6)، ابتدا این کلید میانبر را فعال می‌کنید، سپس تایپ می‌نمایید: f، 6، Enter.

نمونه‌ای دیگر: جهت درج 😍 (صورت خندان با چشم‌های قلبی، کدپوینت یونیکد 0x1f60d)، این کلید میانبر را فعال کرده، سپس تایپ کنید: 1، f، 6، 0، d، Enter.

کلیدهای میانبر شناخته‌شده در حالت ورودی یونیکد:

• کلیدهای Enter، Space: ثبت نویسه یونیکد، سپس خروج از این حالت.
• کلیدهای Escape، q، Ctrl+c، Ctrl+d، Ctrl+g: لغو ورودی، سپس خروج از این حالت.
• نویسه‌های 0-9، a-f: افزودن رقم بعدی به کدپوینت یونیکد.
• کلید Backspace: واگردانی (undo) آخرین رقم.

توجه داشته باشید که در این حالت هیچ بازخورد بصری وجود ندارد. این طراحی هدفمند است؛ حالت ورودی یونیکد foot به عنوان یک راهکار جایگزین (fallback) در نظر گرفته می‌شود. روش ارجح برای وارد کردن نویسه‌های یونیکد، ایموجی‌ها و غیره استفاده از یک IME است.

پیش‌فرض: Control+Shift+u.

گزینه color-theme-switch-dark پوسته رنگی تیره را صرف‌نظر از این‌که در حال حاضر کدام پوسته فعال است اعمال می‌کند.

گزینه color-theme-switch-light پوسته رنگی روشن را صرف‌نظر از این‌که در حال حاضر کدام پوسته فعال است اعمال می‌کند.

گزینه color-theme-toggle بین پوسته‌های رنگی اصلی و جایگزین تغییر حالت می‌دهد.

نکته: شما همچنین می‌توانید سیگنال‌های SIGUSR1/SIGUSR2 را برای تغییر پوسته به فرآیند foot ارسال کنید (برای جزئیات به foot(1) مراجعه کنید).

پیش‌فرض: none

اما با مثلاً URLهای OSC-8 (نسخه ترمینالی لنگرهای HTML، یعنی «پیوندها»)، متن روی صفحه می‌تواند چیزی کاملاً متفاوت از خود URL باشد.

این اقدام بین نمایش و پنهان کردن URL روی برچسب پرش تغییر حالت می‌دهد.

پیش‌فرض: t.

صفحه جایگزین (Alt screen): در صورت فعال بودن حالت پیمایش جایگزین، رویدادهای ساختگی KeyUP را به برنامه کلاینت ارسال می‌کند.

پیش‌فرض: BTN_WHEEL_BACK

صفحه جایگزین: در صورت فعال بودن حالت پیمایش جایگزین، رویدادهای ساختگی KeyDOWN را به برنامه کلاینت ارسال می‌کند.

پیش‌فرض: BTN_WHEEL_FORWARD

اگر یک نقل‌قول کامل در سطر منطقی جاری یافت نشود (تنها یک نویسه نقل‌قول، یا هیچ‌کدام یافت نشود)، کل سطر انتخاب می‌شود.

انتخاب با رها کردن دکمه نهایی شده و در انتخاب اولیه رونوشت می‌شود.

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

نکات:

• نویسه‌های نقل‌قول اسکیپ‌شده پشتیبانی نمی‌شوند ("foo \"bar" با 'foo \' تطابق می‌یابد، نه با 'foo "bar').
• نرم‌افزار foot تلاش نمی‌کند نویسه‌های نقل‌قول نامتقارن را مدیریت کند؛ آن‌ها به سادگی تطابق پیدا نخواهند کرد.
• نقل‌قول‌های تو در تو (با استفاده از نویسه‌های نقل‌قول مختلف) پشتیبانی می‌شوند.

پیش‌فرض: BTN_LEFT-3.

پیش‌فرض: lanczos3.

یک مورد استفاده برای این ویژگی قلم‌هایی با نویسه‌های مورب عریض هستند که به سلول بعدی «خم» می‌شوند. بدون این گزینه، چنین گلیف‌هایی «بریده‌شده» به نظر خواهند رسید.

مورد استفاده دیگر قلم‌هایی با نویسه‌های «آیکون» در ناحیه استفاده خصوصی یونیکد هستند، مانند قلم‌های Nerd، یا قلم‌های Powerline و نویسه‌های ایموجی قدیمی مانند WHITE FROWNING FACE.

نکته: ممکن است بسته به قلم مورداستفاده بر کارایی تأثیر بگذارد. به‌ویژه اندازه‌های کوچک قلم به دلیل رندر ساب‌پیکسل می‌توانند گلیف‌های سرریزکننده زیادی ایجاد کنند.

پیش‌فرض: yes.

در صورت غیرفعال بودن، در عوض به صورت الگوی شطرنجی و با استفاده از همان رنگ پیش‌زمینه جاری رندر می‌گردند.

پیش‌فرض: yes.

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

راهکار واقعی برای این موضوع، به‌روزرسانی‌های همگام برنامه‌ها (Application Synchronized Updates) است (https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/2).

مشکل این ویژگی دوگانه است - نخست، هنوز استانداردسازی نشده است، و بنابراین شبیه‌سازهای ترمینال زیادی نیستند که آن را پیاده‌سازی کرده باشند (foot آن را پیاده‌سازی کرده است)، و دوم، برنامه‌ها باید برای استفاده از آن وصله شوند.

تا زمانی که این اتفاق بیفتد، foot یک راهکار موقت ارائه می‌دهد؛ تلاشی برای کاهش چشمک‌زدن صفحه بدون تأثیر بر کارایی یا تاخیر.

این رویکرد مبتنی بر این واقعیت است که صفحه در فواصل زمانی ثابتی به‌روز می‌شود (معمولاً ۶۰ هرتز). برای ما، این بدان معناست که فرقی نمی‌کند فریم جدید را در ابتدای یک بازه فریم رندر کنیم یا در انتهای آن. بنابراین، هدف ایجاد تاخیری بین دریافت داده‌های کلاینت و رندر وضعیت حاصل است، اما بدون ایجاد پرش فریم.

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

خب، متن زیادی شد. اما آنچه foot در عمل انجام می‌دهد چیست؟

هنگام دریافت داده‌های کلاینت، تایمری را زمان‌بندی می‌کند: delayed-render-lower. اگر پیش از پایان تایمر هیچ داده دیگری از کلاینت دریافت نکنیم، فریم را رندر می‌کنیم. با این حال اگر داده‌های بیشتری دریافت کنیم، تایمر دوباره زمان‌بندی می‌شود. یعنی هر بار که داده‌های کلاینت را دریافت می‌کنیم، رندر فریم به اندازه delayed-render-lower نانوثانیه دیگر به تعویق می‌افتد.

اکنون، با این‌که این روش با بیشتر کلاینت‌ها بسیار خوب کار می‌کند، اما ممکن است کلاینت مخربی ساخته شود که پیوسته داده‌ها را با سرعتی آهسته بنویسد. برای کاربر، این به نظر می‌رسد که foot قفل کرده است چرا که هرگز به رندر فریم جدید نمی‌رسیم. برای جلوگیری از این موضوع، یک سقف بالایی تعیین شده است - delayed-render-upper. اگر زمان این تایمر به پایان برسد، فریم را بدون در نظر گرفتن کاری که کلاینت انجام می‌دهد رندر می‌کنیم.

هنگام تغییر این مقادیر، توجه داشته باشید که مهلت پایینی باید کمتر از مهلت بالایی تنظیم شود، هرچند که این موضوع توسط foot اعتبارسنجی نمی‌شود. علاوه بر این، هر دو مقدار باید کمتر از ۱۶ میلی‌ثانیه (یعنی ۱۶۰۰۰۰۰۰ نانوثانیه) باشند.

می‌توانید با تنظیم هر یک از مقادیر روی 0 این ویژگی را به طور کامل غیرفعال کنید. در این حالت، فریم‌ها «در سریع‌ترین زمان ممکن» رندر می‌شوند.

پیش‌فرض: مقدار پایینی=500000 (۰٫۵ میلی‌ثانیه)، بالایی=8333333 (۸٫۳ میلی‌ثانیه - نصف یک بازه فریم).

به طور معمول هیچ دلیلی برای فعال کردن این گزینه وجود ندارد. با این حال، مشاهده شده است که این گزینه مشکلی را در زمینه مقیاس‌بندی کسری در Gnome برطرف می‌کند.

توجه داشته باشید که فعال کردن این گزینه احتمالاً مصرف پردازنده (CPU) و/یا گرافیک (GPU) را (توسط کامپوزیتور، نه توسط foot) افزایش می‌دهد و ممکن است تأثیر منفی بر طول عمر باتری داشته باشد.

پیش‌فرض: no.

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

این گزینه را می‌توان در زمان اجرا با DECSET/DECRST 2027 نیز تنظیم کرد.

همچنین ببینید: grapheme-width-method.

پیش‌فرض: yes

مقدار wcswidth به سادگی عرض تکی تمام کدپوینت‌های تشکیل‌دهنده خوشه را با هم جمع می‌کند.

مقدار double-width همان کار را انجام می‌دهد، اما حداکثر تعداد ستون‌ها را به ۲ محدود می‌کند. این دقیق‌تر است، اما ممکن است برخی برنامه‌ها را با مشکل مواجه کند، زیرا برنامه‌ها معمولاً از wcswidth(3) در ساختار داخلی برای محاسبه عرض استفاده می‌کنند. این امر منجر به مشکلات ناهماهنگی موقعیت مکان‌نما می‌شود.

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

پیش‌فرض: double-width

اگر همچنان می‌خواهید از قلم استفاده کنید، حتی اگر foot فکر کند که تک‌فاصله نیست، این گزینه را غیرفعال کنید.

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

پیش‌فرض: yes

این گزینه میزان حافظه فیزیکی مورداستفاده توسط foot را تغییر نمی‌دهد.

نرم‌افزار foot از ترفند نگاشت حافظه برای پیاده‌سازی رندرینگ سریع پیمایش تعاملی استفاده می‌کند (به طور معمول، اما به طور کلی برای پیمایش‌های «آهسته» نیز صدق می‌کند). برای مثال: نگه داشتن کلید پیکان «بالا» یا «پایین» برای پیمایش در یک ویرایشگر متن.

برای کارکرد این ویژگی، به مقدار زیادی فضای آدرس مجازی نیاز دارد. مجدداً توجه داشته باشید که این حافظه فیزیکی نیست.

در یک رایانه معمولی مبتنی بر x64، هر فرآیند دارای ۱۲۸ ترابایت فضای آدرس مجازی است و پردازنده‌های جدیدتر دارای ۶۴ پتابایت هستند. این مقدار بسیار عظیمی است و بیشتر برنامه‌ها حتی به مقداری نزدیک به آن هم دسترسی پیدا نمی‌کنند.

هر پنجره ترمینال foot می‌تواند تا ۲ گیگابایت فضای آدرس مجازی تخصیص دهد. با ۱۲۸ ترابایت فضای آدرس، این به معنای حداکثر ۶۵۵۳۶ پنجره در حالت سرور/دیمن است (به ازای ۲ گیگابایت). این مقدار باید کاملاً کافی باشد، درست است؟

با این حال، کامپوزیتور Wayland نیز باید همان مقدار فضای آدرس مجازی را تخصیص دهد. بنابراین، احتمال اتمام فضای آدرس در آن کمی بیشتر است، زیرا باید تمام کلاینت‌های در حال اجرای Wayland را به همان شیوه و همزمان میزبانی کند.

در صورتی که این موضوع برای شما مشکلی ایجاد کرد، می‌توانید مقدار مورداستفاده را با این گزینه کاهش دهید.

یا، برای دستیابی به کارایی بهینه، می‌توانید آن را به حداکثر مقدار مجاز، ۲ گیگابایت افزایش دهید (اما توجه داشته باشید که احتمالاً متوجه هیچ تفاوتی در مقایسه با مقدار پیش‌فرض نخواهید شد).

تنظیم آن روی 0 این ویژگی را غیرفعال می‌کند.

محدودیت‌ها:

پیش‌فرض: 512. حداکثر مقدار مجاز: 2048 (۲ گیگابایت).

در برخی شرایط، کامپوزیتور می‌تواند بافرهای SHM برنامه foot را مستقیماً بدون کپی کردن بافر در حافظه GPU، به GPU وارد (import) کند (معمولاً در گرافیک‌های مجتمع). درایورهای مختلف نیازمندی‌های متفاوتی برای این کار دارند، و یکی از آن نیازمندی‌ها معمولاً تراز گام است. در زمان نگارش این متن، پردازنده‌های گرافیکی AMD به تراز ۲۵۶ بایتی نیاز دارند.

توجه داشته باشید که انجام یک ایمپورت مستقیم معمولاً آزادسازی بلادرنگ بافر را غیرفعال می‌کند (اگر کامپوزیتور از آن پشتیبانی کند)، که به این معنی است که foot باید از بافرسازی دوگانه استفاده کند. این امر جریمه کارایی را به foot اضافه می‌کند، اما کارایی کلی سیستم همچنان باید بهتر باشد.

اگر از گرافیک مجتمع استفاده نمی‌کنید، یا اگر کامپوزیتور از وارد کردن مستقیم GPU پشتیبانی نمی‌کند، این گزینه تأثیری نزدیک به صفر دارد. می‌توانید با تنظیم آن روی 0 مقدار کمی از حافظه را ذخیره کنید.

در نهایت، این به عهده کامپوزیتور است که تصمیم بگیرد آزادسازی بلادرنگ بافر را انجام دهد یا برای بهینه‌سازی وارد کردن به GPU تلاش کند.

پیش‌فرض: 256

مقدار auto عمق بیت را بسته به سایر تنظیمات و در دسترس بودن انتخاب می‌کند.

مقدار 8-bit، از ۸ بیت برای هر کانال رنگی، شامل آلفا استفاده می‌کند. این حالت پیش‌فرض در زمان gamma-correct-blending=no است.

مقدار 10-bit از ۱۰ بیت برای هر کانال RGB و ۲ بیت برای کانال آلفا استفاده می‌کند. بنابراین، کانال‌های رنگی با دقت بالاتری را فراهم می‌کند، اما کانال آلفا با دقت کمتری خواهد بود.

مقدار 16-bit از ۱۶ بیت برای هر کانال رنگی، شامل آلفا استفاده می‌نماید. در صورت وجود، این حالت پیش‌فرض در زمان gamma-correct-blending=yes است.

توجه داشته باشید که هر دو حالت 10-bit و 16-bit بسیار کُندتر از 8-bit هستند؛ اگر می‌خواهید از ترکیب تصحیح‌شده با گاما استفاده کنید و سرعت (توان پردازش و تاخیر ورودی) را به رنگ‌های دقیق ترجیح می‌دهید، می‌توانید surface-bit-depth=8-bit را صراحتاً تنظیم کنید.

پیش‌فرض: auto

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

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

بنابراین، فعال بودن این گزینه هم کارایی را بهبود می‌بخشد (رونوشت تغییرات دو فریم آخر ریسمانی می‌شود)، و هم تاخیر ورودی را بهبود می‌دهد (رندر فریم بعدی دیگر مجبور نیست ابتدا تغییرات بین دو فریم آخر را انتقال دهد).

پیش‌فرض: yes