Что вдохновило эту идею
Вдохновение пришло от доклада Скотта Дженсона «Are we really going to use the same Desktop UX forever?» — презентации, блистательной по ясности и лаконичности. Дженсон утверждал, что Apple и Microsoft больше не будут инновировать на рынке настольных ОС, и развитие рабочего стола теперь зависит от сообщества разработчиков. Хотя, добавляет автор, ситуация более нюансирована: они пробуют идеи, но крайне консервативно. Многое из того, что считается базовой парадигмой, — это костыли для железа, который давно не используется.
Суть предложения: сделать tmux доступным для обычных пользователей. Это потрясающая система с прокруткой, сохранением сеансов, отсоединяемостью и ориентацией на задачи, но требует командной строки. Возможно ли перенести этот опыт на рабочий стол?
Главные проблемы управления окнами в 2026 году
Экран постоянно меняется, и его становится больше
Переход с ноутбука на большой монитор или двойной экран происходит примерно 6 раз в день. При множественных мониторах перекрывающиеся окна теряют смысл — места хватает. Исследование Грудина 2001 года показало, что люди используют второй монитор асимметрично: первый — для основной работы, второй — для справочной информации. Прошло 25 лет, а ОС всё ещё не различает эти роли.
При отсоединении ноутбука от док-станции всё схлопывается на один экран, и приходится вручную перемещать и изменять размер окон. Ощущение, что время на это тратится впустую. ОС рассматривает изменение дисплея как неожиданность, а не как регулярное событие.
Люди используют окна совершенно по-разному
Есть три группы пользователей, которые видят рабочий стол принципиально по-другому:
- Максимизаторы: почти каждое окно занимает весь экран, переключение через Command+Tab или панель задач.
- Почти-максимизаторы: одно большое окно плюс несколько маленьких для справки (статусы, чат, почта).
- Координаторы: тщательно раскладывают все окна на экране.
Почти каждый пользователь различает «публичные» и «приватные» окна. Первые можно показать другим, вторые лучше скрыть — например, персональные данные при подключении к проектору. Это было измерено ещё в 2004 году в исследовании «Revisiting Display Space Management», и ОС так и не адаптировалась к этому паттерну.
Браузер стал мини-операционной системой
В 2026 году очевидно: большинство приложений работает в браузерных вкладках. Но ОС относится к браузеру как к обычному приложению, хотя это скорее виртуализированная ОС внутри хост-системы.
Вкладки браузера и окна имеют ту же сложность, что и другие приложения. Вкладки связаны с потоками работы: можно писать Terraform в Vim, одновременно читая документацию провайдера. Но связь между вкладками и задачами размыта. Одна вкладка «работает» сразу в нескольких задачах.
Файловая система как все более слабое понятие
Заметки в Apple Notes хранятся в облаке, а не в файловой системе. СМС живут в базе iMessage, Slack-сообщения — в приложении. Браузер показывает PDF, но он не попадёт в Documents, пока вы это не сделаете вручную.
С 2004 года есть отличное исследование CHI с названием «Stuff goes into the computer and doesn't come out». Проблема актуальна до сих пор: всё ломается в цепочке файл → приложение → файл → отправить, если содержимое не живёт где-то, где его видит ОС.
Что уже пробовали
Проблема известна давно. В 1986 году Хендерсон и Кард описали концепцию виртуальных рабочих пространств (Rooms), уже осознавая, что текущая система управления окнами неудовлетворительна. Их дизайн был весьма передовым для того времени.
Хендерсон и Кард применили аналогию с памятью: экран — это ОЗУ, закрытое окно — страница на диске. Окна не трогаются случайно; люди работают в наборе из 2-10 окон (это задача), и 98% времени проходит внутри этого набора. Заметная часть затрат приходится на 2% переключения. Rooms предварительно загружал следующий набор, что авторы назвали «снижением knowledge faulting in the user» — лучшая фраза в научной литературе.
Интересная попутная работа — «No Task Left Behind? Examining the Nature of Fragmented Work», которая подтвердила давнее подозрение: люди не сосредотачиваются на одной задаче надолго. Они жонглируют примерно десятью «сферами работы» в день, по несколько минут каждая. Одна из цитат участника: «Constant, constant, multi-tasking craziness».
Ближайший прецедент — статья WindowScape: Task Oriented Window Manager. Система отказалась от явного группирования и вместо этого делала снимки состояния. При переходе в новое состояние вы возвращаетесь к снимку, а не заполняете контейнеры. Авторы элегантно диагностировали все предыдущие системы: «требовать, чтобы окна были в одной группе, заставляет пользователей решать заранее, где принадлежит новое окно». Снимки позволяли одному окну появляться в нескольких состояниях — люди понимают, что в разных фотографиях может быть один и тот же объект. Недостаток: снимки исчезали. Это разрыв, который стоило бы закрыть.
Для проблемы перекрывающихся окон уже есть решение — тайлинговые менеджеры окон, максимизирующие использование экрана при переключении между раскладками без ручного изменения размеров. Но у них две беды:
- Они неимоверно сложны для обычных пользователей. Если инструкция начинается с «откройте файл конфигурации», всё кончено. Типичный туториал по тайлингу просит клонировать репозиторий раньше, чем открыть окно.
- Нужен прокручиваемый тайлинговый менеджер — способность установить конфигурацию, отложить её в сторону, затем прокрутить вправо и делать что-то совсем другое, как если бы сунули беспорядок в ящик. Бесконечное пространство без разделения на macOS Spaces.
К счастью, такое уже существует — Niri. Нужно просто облегчить его использование. Основные механизмы работают.
Проблему браузера как ОС люди пытались решить, но в неправильном направлении: делали браузер ещё больше похожим на ОС, вместо того чтобы сделать его содержимое первоклассным гражданином хост-системы. Arc браузер и Chrome OS — главные примеры. Arc интереснее: сдвинул вкладки из верхней части в боковую панель и по сути захватил концепцию окон у ОС.
С логикой «браузер — теперь ОС» всё понятно, но это фундаментально ошибочная идея. Если веб-приложение работает как приложение, оно должно быть отдельным окном. Если оно дополняет другое приложение, оно должно быть окном, связанным с этим приложением, и содержать много вкладок — браузер как портал для всех справок и исследований.
Кладбище попыток решения
Windows Timeline (2017–2019): вся активность по всем приложениям, отсортирована и организована.
Windows Sets (2018–19, отменено): приложения и веб-страницы в общих вкладках. Это было ближайшее к предложению: сама ОС группировала приложения и веб-содержимое в задачи.
macOS Stage Manager (2022): автоматическое группирование окон по задачам, встречен прохладно. На планшете модель «одно в раз, быстрое переключение» имеет смысл, но на столе два-три окна должны работать вместе. Stage Manager скомпрометировал себя в сторону iPad и не справился ни с одной целью.
KDE Activities: всё написанное здесь — уже знакомая история для KDE. Они занимаются управлением состояния рабочего стола по задачам более десяти лет. Система решает большинство проблем из статьи, но требует ручного настроения и конфигурирования. KDE дизайн-документы отличные, стоит прочитать.
PWA install: уже даёт веб-приложениям собственное окно без браузера-хрома, неловко, но хотя бы делает их «настоящими» приложениями.
Почему ничего из этого не взлетело? Timeline требовала opt-in от приложений, большинство не подключились. Она логировала всё, что казалось creepy. Sets умер где-то между стратегией и совместимостью приложений. Stage Manager пытался быть универсальным и никого не порадовал. KDE Activities — opt-in, а opt-in означает, что те, кому нужно, никогда не настроят.
Паттерн на кладбище: идеи правильные, просто не по умолчанию или не на уровне ОС, где видны все приложения. Всё нужное должно быть структурным.
Файловая система как слабая абстракция
ОС пытались это решить, но без требования использовать файловую систему ОС для документов нет консистентности. macOS имеет «Recent files», но это понятие размыто. Система кажется совсем сломана или работает по критериям, которые неочевидны.
Десятки документов открыты, загружены и созданы с 23 сентября, а что было недавно — совсем неясно. Может быть, это сломано. Может быть, это работает по критериям, которые не имеют смысла. Или это персонально.
Но идея правильная. Идеальное состояние: «по всему компьютеру и приложениям, с какими файлами я недавно работал», расширенное на письма, Teams, Slack и всё остальное. Один экран для всего, поиск везде, без разницы, где это хранится. Microsoft пробовал, людям не нравилось, но концепция имеет смысл.
Что может помочь разобраться сейчас
Что изменилось? Почему эта проблема может быть решена сейчас, когда раньше было слишком сложно? Локальная LLM может помочь, если найти способ, при котором выигрыш больше потерь.
Идея организации вокруг задач. Когда определяешь задачу, она позволяет собрать все окна вместе, включая отдельные браузерные вкладки, связанные с задачей, а не с браузером. Остаётся гибкость определения glanceables, которые живут вне строгого тайлинга.
Основной поток окна выглядит так:
Рабочий стол — это один бесконечный холст; каждый физический дисплей — окно просмотра в нём
Результат: контракт переходов для решения проблемы многих мониторов:
- Никогда не меняются: горизонтальный порядок окон, позиция прокрутки, фокус ввода, принадлежность задаче.
- Перетекают детерминированно: ширина колонок, как адаптивный макет. Когда полка сужается, книги остаются в порядке, крайние правые выходят за край просмотра в область прокрутки.
- Состояние, воспроизводимое при переподключении: цели окна просмотра. Два монитора означают два окна просмотра, направленные в две области — одно на основную задачу, одно на glanceables. Отсоединение: второе окно исчезает; его область в одной прокрутке. Переподключение: оно вновь нацеливается туда, где было.
ОС наконец узнаёт, какой монитор основной
Дисплей, получающий нажатия клавиш примерно 90% времени, основной; окна, которые остаются видимы, но редко получают фокус — glanceables. Это выводимо из телеметрии фокуса и не требует отслеживания глаз или конфигурации. Когда экран ноутбука маленький, glanceables понижаются до тонкой полосы, а не полных плиток — ровно то, что уже делает tmux.
Один субстрат для всех трёх типов пользователей
Помните максимизаторов, почти-максимизаторов и координаторов? На холсте они просто разное количество колонок. Максимизатор — одна полноширинная колонка. Почти-максимизатор — одна колонка плюс полоса glance. Координатор — N колонок. Никто ничему не принужден. Вот почему дизайн может быть по умолчанию, где KDE Activities была предпочтением: субстрат не навязывает стиль, просто прекращает штрафовать тот, который у вас уже есть.
Приватность как встроенный примитив, управляемый состоянием машины
Приватное — это свойство окна или вкладки, не региона экрана. Приватный контент визуализируется скрыто, если машина может гарантировать безопасность. Правило: выводить состояние приватности из наблюдаемых фактов, как подключённые дисплеи или активные сеансы захвата, никогда из выведенных человеческих состояний вроде внимания или простоя.
Подключение нового дисплея показывает экран «готово к презентации». Вы явно нацеливаете его: эту задачу, это окно, или расширяете холст. Известные дисплеи пропускают танец. Экранный шеринг — то же событие без кабеля. Если дверь не откроется, модели не нужна дисциплина, а если по умолчанию не может утечь, пользователю не нужна память.
Ничего из этого не экзотично. Apple Keynote с видом презентации (слайды на проекторе, заметки на экране) существует 20+ лет. Apple никогда не продвигала паттерн до уровня ОС, хотя смысл очевидный. Предложение: presenter view как десктопный примитив.
Вкладки браузера отсоединяются в настоящие окна и присоединяются к своей задаче
«Браузер» перестаёт быть местом, где живут окна.
Всё это имеет смысл, пока не доходит до «как организовать это по задачам». Продвинутые пользователи смогут это делать, но идея в том, что они никогда не должны спускаться в конфиг-файл. Мышка и перетаскивание слишком неловко для того, как это работало бы. В идеале можно попросить что-то с доступом к информации внутри каждой браузерной вкладки и окна, помочь организовать в логический поток.
Вот здесь и нужна локальная LLM.
Это называется «quake overlay», потому что автор старый и всегда любил идею текстового ввода, падающего сверху с универсальным сочетанием клавиш (как quake terminal). Молодёжь знает этот паттерн из Discord overlay. На предыдущей диаграмме показано как более дружелюбное «Ask» окно.
Основной поток: попросить LLM помочь организовать, она показывает свои рассуждения, запрашивая информацию через ограниченный MCP-сервер с набором глаголов, затем даёт превью будущей раскладки. Модель никогда не трогает менеджер окон прямо. Она предлагает, вы нажимаете yes.
Люди редко берутся за совсем новые задачи: графический дизайнер всю жизнь делает «открыть файлы из сети, изменить, сохранить результат, вставить в чат, повторить». Редко кто сидит в новых контекстах дисплея: ноутбук один, стол, конференц-зал. Редко кто подключает новые дисплеи. Новизна редка везде, поэтому дорогая машина classify, propose, preview, confirm запускается редко, а всё остальное — детерминированное воспроизведение. Организуешь ограниченный набор задач один раз и переиспользуешь вечно. Проверять тикеты, открыть Vim и браузер, работать тикет, написать обновление, открыть PR, опубликовать на ревью, следующий тикет. Конфиг можно сделать кошмаром JSON и перестать заботиться, потому что единственный читатель — модель, которой всё равно.
Главная проблема — пространственная память. Люди помнят, где что находится на компьютере, и не любят, когда это меняется. Как если бы кто-то перетасовал твой физический стол и подвинул кресло. Вероятно, нужно строго соблюдать модель «добавь, не заменяй».
Есть название для этого. Кирш и Магличо называют это epistemic action — когда игроки в Тетрис вращают фигуры больше, чем требуется, потому что вращение — это как они думают о фигуре. Раскладка окон — это мысль в процессе. Помощник, который её «оптимизирует» посередине, прерывает.
Это проблема, с которой столкнулся при попытке реализовать идею. Современные LLM на самом деле плохи в «трогай это, никогда не трогай то». Неясно, реалистична ли идея. Скучное решение: LLM предлагает, тупой детерминированный код выполняет, исполнитель отказывается трогать закреплённое. Не нужна дисциплина модели, если дверь не откроется.
Всё ещё нужен высокоуровневый UI-элемент для пользователей, и здесь более инклюзивное понимание файловой системы может помочь.
Задачи становятся примерно сравнимы с директориями. Но всё вытекает из высокоуровневой концепции «задачи» и течёт в индивидуальные вещи. Одно приложение никогда не является задачей. Это «некоторое окно чата, браузер, может быть Preview». Можно ли попробовать это построить?
Попытка реализации
Надежда была опубликовать рабочий Linux-десктоп с примером. Но оказалось (неудивительно), что сделать такое работает безумно сложно. Некоторые базовые идеи работают разумно (глобальное выпадающее окно терминала сверху, прокручиваемые плитки), но всё ещё неловко. Будет продолжать, и если интересно — добавьте в RSS или просто ждите.
Для полной честности: это потребует много выходных для простой рабочей демонстрации. Буду стараться, но потерпите.
Почему этот дизайн ломается
При попытке запустить это в Linux VM немедленно столкнулись с серьёзными логическими проблемами. Кажется, неудачи часто интереснее читать, чем успехи.
Дизайн с приватностью работает на данных, которые требуют надзора
Есть ирония, с которой пришлось сидеть. Дизайн обещает, что ОС наконец узнает, какой монитор основной — то, что Грудин измерил 25 лет назад, — а механизм это телеметрия фокуса ввода. Смотрим, какой дисплей получает нажатия. Смотрим, какие окна редко получают фокус. Сохраняем со временем. Менеджер окон, дружелюбный к приватности, хочет знать о вас больше, чем текущая ОС. Сохраняй локально, сохраняй эфемерно, но это всё ещё много поведенческих данных для управления системой. Просто наблюдение, что каждый механизм в статье голоден по данным, которые исторически дерайлили идеи вроде этой.
Любимая функция приватности была шуткой
Исходный план был элегантен: приватный stuff далеко слева, публичный справа, и когда ты неактивен, окно просмотра дрейфует назад на публичное. Как если бы друг сменил тему для тебя. Потом запустили, и первое, что узнали: чтение — это состояние неактивности. Прекращаешь печатать чтобы прочитать, и система начинает прокручивать это подальше. Тем временем, человек проходящий мимо видит всё, потому что «приватное» окно на большом мониторе не скрыто, оно просто далеко слева. Приватность через затенение нужна чтобы знать о угрозе, и угроза — это пешеход, которого не обнаружить.
Ничто в этом дизайне никогда не устаревает
Холст бесконечен, правило append-only, пространственная память священна, поэтому беспорядок растёт монотонно. Решили проблему электронного беспорядного стола, купив ему бесконечный стол. Когда впервые прочитали WindowScape, назвали испаряющиеся фотографии «разрывом для закрытия». Изменили мнение, потому что испарение тихо делало работу сборщика мусора. Что-то должно перейти в спящий режим без перемещения, но решение, что идёт в спящий режим — это решение жатвы, а жатва точно то, что append-only запрещает. Не потребовалось долго, пока бесконечный десктоп почувствовался подавляющим при попытке.
Развлекательный эксперимент
Неизвестно, хороша ли эта идея, но освобождает перестать ждать, пока macOS и Windows сделают что-то лучше или интересное в этом пространстве, и решить попробовать самому. Кладбище полно хороших идей, умерших от распределения. Пора для радикального эксперимента, который поставляется по умолчанию.
Самая поучительная часть — как много исходный дизайн перекрывающихся окон был костылём для аппаратных ограничений и как скоро люди ясно увидели проблемы. Удивительно, как часто это случается в технологии: видишь проблему, ищешь академические статьи о ней и находишь огромное богатство информации от людей, говорящих «ага, это 100% проблема, которую мы должны решить скоро». Может быть, эта статья вдохновит кого-то умнее решить это наконец.