ADR 0074: UI настроек — компактнее, якорь на MFD; нехватка места в раскладке P+F+M¶
Статус: Proposed
Дата: 2026-04-19
Связанные ADR¶
| ADR | Роль |
|---|---|
| 0029 | канон TOML; целостный центр настроек deferred; точечный UI = фасад канона |
| 0028 | settings.toml |
| 0021 | якоря PFD / Forward / MFD |
| 0046 | presentation, инварианты раскладки |
| 0017 | мультиоконность, display.screens |
| 0069 | пример MFD-first tool surface |
Вне ADR¶
| Документ | Роль |
|---|---|
Models/MfdShellPage.cs |
enum страниц MFD |
Контекст¶
Ожидание пользователя: настройки логично искать в вторичном контуре «домашних» инструментов — MFD (0021), а не как единственный тяжёлый модальный слой поверх редактора, если цель — не потерять контекст кокпита.
Факт кода: часть настроек уже доступна как страница AiChatSettings в MfdShellView; полный набор по-прежнему открывается отдельным окном (меню «Настройки → Параметры AI и чата…» → OpenSettingsCommand → ShowSettingsWindow). 0029 не запрещает развитие UI, но фиксирует deferred отдельный «полноэкранный центр настроек как отдельный продукт»; перенос в MFD — это не вторая правда на диске, а поверхность над тем же CascadeIdeSettings.
Проблема плотности: в типичной раскладке P + F + M (PFD | Forward | MFD) колонка MFD ограничена по ширине; длинные формы и много секций дают scroll, обрезание или ощущение «тесноты» — нужна явная политика при нехватке места.
Предлагаемое направление (черновик)¶
- Целевой якорь: основной UI редактирования настроек (или его большая часть) — внутри MFD (вторичный контур), компактная вёрстка: группы, аккордеоны, короткие пути к редким ключам, ссылка «открыть
settings.toml» без дублирования канона. - Отдельное окно: оставить как fallback (большой монитор, сравнение сбоку, доступность) или свернуть до редких сценариев — решение продукта после прототипа MFD.
- Согласовать с 0029: любой UI по-прежнему фасад модели и файлов; расширение экрана MFD не добавляет второй источник истины.
Открытые вопросы: нехватка места (P + F + M и др.)¶
Зафиксировать одну или иерархию стратегий (подлежит выбору):
| # | Стратегия | Смысл | Риск |
|---|---|---|---|
| 1 | Вертикальный scroll внутри страницы MFD | Простой baseline | Длинные формы «убегают» вниз; нужна липкая навигация по секциям |
| 2 | Минимальная ширина MFD + пользовательский ресайз колонки | Сохранить читаемость | На узких экранах конфликт с Forward (редактор) |
| 3 | Полноэкранный режим только для MFD (развернуть колонку / временно max ширина) | Компромисс без отдельного окна | Нужен явный жест выхода / восстановление пресета |
| 4 | Отдельное окно как fallback при ActualWidth < threshold |
Предсказуемо на малых дисплеях | Два кода пути или адаптивный контейнер |
| 5 | Второе окно (уже есть для MFD host в 0017) — дублировать настройки туда | Много мониторов | Синхронизация фокуса и «где правда открыта» |
| 6 | Сворачивание PFD (авто или по политике) при фокусе на настройках | Больше места под форму | Меняется модель внимания без явного действия пользователя — осторожно (0021) |
Рекомендация для обсуждения: начать с (1) + (2) и явного breakpoint для (4); (6) — только по явной команде пользователя, не автоматически в v1.
Решение¶
Зафиксировать как Proposed: направление «настройки → MFD, компактнее» и перечень открытых стратегий overflow — не как немедленная смена 0029 (канон на диске не меняется), а как продуктовый и UX выбор следующей итерации.
Следующий шаг: прототип или рефакторинг разметки страницы настроек в MfdShellView; измерить минимальную ширину и поведение на 1366×768 и ультрашироком экране; записать выбранную политику из таблицы overflow в этот ADR или в presentation / capabilities (0046).
Последствия¶
- Плюс: согласованность с ментальной моделью «настройки рядом с чатом/терминалом» на MFD; меньше отрыва от кокпита.
- Минус: инженерная работа по адаптивной вёрстке и тестам; нужно не сломать пользователей, привыкших к отдельному окну — migration path (пункт меню → сначала MFD, «Открыть в отдельном окне» опционально).