Обзоры
Оконный менеджмент – ПК против рабочей станции
0

Оконный менеджмент – ПК против рабочей станции

Workstation и PC

В давние времена, когда самым мощным микропроцессором заслуженно считался легендарный Motorola 68000, деление настольных компьютеров на классы было весьма условным. Предшественники ПК отличались не столько аппаратной простотой, сколько невысоким уровнем развития системного и инструментального ПО: обычно речь шла об управляющей программе-мониторе и встроенном интерпретаторе языка программирования Basic. С приходом в микромир мобильной инструментальной ОС Unix ситуация изменилась и предопределила сегодняшнюю "расстановку сил". Первые успешные производители универсальных вычислительных машин ПК-класса ограничили целевую категорию своей продукции и, соответственно, пошли по единственно правильному пути — ограничению функциональности системного ПО и базовых инструментальных средств.

Впоследствии ПК-мир приобрел самую главную отличительную черту: инструментальные средства навсегда "оторвались" от системного ПО — их выделили в отдельную (отличающуюся достаточно высоким уровнем цен) категорию программ. Сокращение функциональности достигло апогея: любая современная пользовательская ОС в базовой конфигурации практически не предлагает ни одной возможности пользователю в части расширения функциональности — что в ней есть, то и есть, а все остальное можно получить от сторонних прикладных/системных программ. Слово "остальное" в данном случае семантически эквивалентно целой фразе "класс задач, для решения которых кто-то создал определенную прикладную программу", а слово "можно" подразумевает тот очевидный факт, что для некоторых классов задач никто еще не создал никаких программ.

Естественно, узкая категория пользователей, заинтересованная в слишком обширном классе "несуществующего ПО" (а он действительно необъятен), так и осталась приверженной инструментальным ОС, а массовый рынок отдал предпочтение системам с ограниченной способностью к расширению функциональности. Удивительно другое — заинтересованное в инструментальном характере ПО международное сообщество ученых, инженеров и высококлассных специалистов computer science, не страдающее ни хроническими болезнями корпоративной келейности и закрытости, ни приверженностью к сиюминутным модным течениям, по сей день не смогло радикально улучшить детище гениальных разработчиков Bell Labs — инструментальную ОС Unix или создать ей достойную альтернативу.

Но пользователи рабочих станций — тоже люди, ничто человеческое им не чуждо — в их мире есть свои понятия "удобства" и "дружественности" ПО. Первая полноценная и по сей день привлекательная своими возможностями компонентная графическая оболочка CDE (Common Desktop Environment), ровесница робкого недоразумения Windows 3.1, поражает удачными архитектурными решениями и удобством использования, а большинство не принятых по непонятным причинам идей и программ, проработанных в академическом сообществе с очень высоким уровнем качества, остаются совершенно уникальными в обоих мирах — и ПК, и рабочих станций.

Управляя окнами

Современная рабочая станция без графической подсистемы — это абсурд, и никаких доказательств такое утверждение не требует. Тем более, что наличие графической подсистемы ни в коей мере не навязывает (или, точнее, в рамках хорошо спроектированной ОС не должно навязывать) негибких механизмов взаимодействия с компьютером. Парадокс? Вовсе нет — просто следует четко различать возможности графической подсистемы компьютера в части визуализации данных и приема пользовательских команд. Если первые действительно потрясающи и бурно развиваются, то вторые до неприличия тривиальны: кнопки, ниспадающие меню, поля ввода строк, маркер и шкалы — вот почти и весь перечень интерфейсных элементов, на которых строится "дружественность". Для сокращения количества необходимых действий при активации тех или иных тривиальных функций этого набора более чем достаточно, в остальных же случаях в мире ПК выручает установка дополнительного ПО (если таковое имеется), в мире рабочих станций — традиционные приемы скриптинга.

Последнее утверждение в полной мере относится и к графическим "способностям" распространенной комбинации Unix/X Window. Но об этом — позже. А пока сконцентрируемся на крайне редко рассматриваемом вопросе, а именно, — на возможностях пользовательского интерфейса по… управлению окнами.

Удивительно, но вопросу оценки эргономичности программной подсистемы, присутствующей в любой ОС с графическим интерфейсом, — оконного менеджера (ОМ) — практически никто не уделял внимания. А ведь ОМ есть действительно в любой ОС, и даже не важно, как именно называется его реализация в терминах разработчиков или пользователей, главное — программа (модуль/подсистема/компонент), управляющая размещением окон на экране вашего компьютера, обязательно существует. И можно найти очень весомые латентные показатели ее качества, определяющие массу привычек, стилей работы и даже… физиологических расстройств.

Впрочем, давайте сразу перейдем к попытке сравнительного анализа. Увы, без сравнений здесь обойтись не удастся. И начнем с того, что, по субъективному мнению автора, свойственно оконным менеджерам современных массовых пользовательских ОС. Прекрасно знакомая большинству ОС Windows, считающаяся эталоном в эргономике, при детальном рассмотрении механизмов управления окнами оказывается не такой уж и удобной. Установленное по умолчанию несоответствие между расположением taskbar ("панель задач" в терминах Windows) внизу экрана и обрамлений окон — на верхней стороне окна приводит к слишком большой нагрузке на кисть руки при любых попытках организовать удобную многооконную работу.

Каждый пользователь Windows может в этом убедиться сам. Перемещение окна способом "перетягивания за обрамление" и восстановление на экране "свернутого" в кнопку taskbar окна любого другого приложения с коррекцией его положения требует большого количества "длинных" движений мышью: вверх — к обрамлению первого окна, вниз — к taskbar, вверх — к обрамлению второго окна.

Разработчики Mac OS оказались более внимательными и разместили taskbar по умолчанию вверху экрана. Движения мыши в этом случае стали намного "короче". Естественно, taskbar можно переместить вверх, но оконный менеджер Windows при стандартных установках готовит еще ряд очень неприятных эргономических сюрпризов. Так, в режиме полиоконной работы (когда на экране одновременно присутствует много окон открытых приложений) "длинные мышиные рейды" частично компенсировались бы возможностью "перетягивания" окна при использовании любой точки обрамления, а не только верхней его части (в какой-то мере потому, что точное позиционирование курсора с помощью мыши на узкую полоску обрамления окна — сильно утомительная как для глаз, так и для рук задача). В подтверждение справедливости вышесказанного можно привести только одно, достаточно объективное наблюдение: полиоконный режим работы в ОС Windows не прижился, пользователи предпочитают фактически одноэкранный режим с часто повторяющейся операцией "свернуть/развернуть".

К слову, еще одним стимулятором такой привычки стала одна из особенностей… шрифтов с антиалиайзингом. Простой эксперимент показывает, что при малых размерах отображаемых символов "сглаженные" шрифты очень плохо читаются — намного хуже обычных bitmapped (отображаемых пиксельной картой). А естественная реакция — увеличение размеров отображаемых шрифтов — приводит к увеличению и размеров окон приложений вплоть до "верха совершенства": один экран — одно окно.

Полиоконные возможности ОМ Windows значительно ухудшены невысокой гибкостью базовой системы по управлению процессами позиционирования окон и их сокращенного представления. Об одном недостатке позиционирования уже упоминалось (невозможность использования любой точки обрамления в качестве "зацепки" для перемещения окна, вызывающая потребность в "длинных" перемещениях мыши), второй же — приводит к настоящей буре двигательной активности кисти при полиоконной работе. Увы, автору не удалось отыскать способ перемещения окон в этой системе без дополнительных манипуляций — с помощью так называемых shortcut-движений. Последнее подразумевает перехват оконным менеджером нажатий некоторых клавиш (shortcut) при нахождении курсора в окне приложения и активации действий с окном при перемещении мыши с одновременно нажатой shortcut-клавишей.

Сокращенное представление окон — еще одна "болезнь" ОМ Windows. Все, что возможно в базовой конфигурации системы, — "свертывание" окна в кнопку на taskbar — далеко от совершенства. Ведь обратный процесс требует опять же "длинного" перемещения мыши, а при большом количестве свернутых окон мешанина узких кнопочек на taskbar становится абсолютно неинформативной и существенно затрудняет работу (в подтверждение сказанному: в Windows XP, наконец, эта "болячка" будет в какой-то мере устранена группировкой приложений на одну общую кнопку taskbar с сопровождающим выплывающим навигационным меню).

Но все же модель "taskbar+кнопки" остается далекой от навигационного удобства, например, свернутых до верхней части обрамления окон (каноническая модель сокращенного представления окон Mac OS). Подобные "остатки" в виде узкой полоски с отлично читаемым заголовком (ведь горизонтальный размер окна при такой модели сокращенного представления сохраняется) легко позиционировать, развертывать, они не занимают много места на экране и не требуют утомительных для кисти манипуляций с мышью. Однако базовая модель ОМ Windows ничего подобного не позволяет.

Еще ни разу не упомянутое управление моделью фокуса — тема отдельного обсуждения. Принятая по умолчанию в ОМ Windows фокусная модель "point & click" ("указать курсором и подтвердить указание нажатием кнопки мыши") — одна из самых нелюбимых активными пользователями компьютеров, ведь она требует как минимум одного лишнего действия — для указания системе направления клавиатурного ввода. Это не просто утомительно — при полиоконном режиме "point & click" фокус часто приводит к досадным ошибкам.

При более совершенной фокусной модели FFM ("Focus Follows Mouse", в терминах Windows почему-то именуемая "X-mouse", хотя к X Window она, по большому счету, никакого отношения не имеет) клавиатурный ввод автоматически направляется в окно, в пределах которого находится в данный момент курсор. Фокусная модель FFM в ОМ Windows реализована, но… без манипуляций с реестром недоступна.

Еще один серьезный недостаток в области управления фокусом кроется в невозможности для пользователя управлять положением произвольного окна в так называемом "стековом порядке" (отражающем расположение окон "по глубине" экрана) указаниями ОМ наподобие "Всегда отображать это окно поверх других!". При полиоконной работе такая функция далеко не лишняя, но и она в базовом ОМ Windows недоступна.

И наконец, предпоследний (в нашем коротком анализе) момент — полиэкранный режим. Опять же, увы, — штатному ОМ Windows такая задача "не по зубам". Конечно, можно определить виртуальный десктоп с разрешением, большим реального разрешения экрана, но пользоваться этой комбинацией без удобных средств навигации и управления практически нельзя (что опять же подтверждается абсолютной непопулярностью виртуальных десктопов в Windows-мире). А ведь полиэкранный режим — не технологическое ухищрение, необходимое только для "украшательства". Это, скорее, один из важнейших элементов организации полноценной работы с компьютером, которому следует уделить достойное внимание. И вот почему: как ни сложно с этим сразу согласиться, но каждый экран (десктоп) компьютера с открытыми окнами является элементом определенной структуры. Для оконного менеджера эта структура важна по технологическим причинам, для нас же — возможностями упорядочения хаоса приложений.

Используя виртуальные экраны, можно легко моделировать ролевой стиль работы с компьютером: за этим экраном реальный "я" становлюсь Web-серфером, за этим — журналистом, за этим — программистом, а здесь — просто отдыхаю, проводя время за любимыми занятиями. И возникают эти экраны автоматически при запуске графической подсистемы, и приложения стартуют и размещаются также автоматически там, где мне нравится. И для навигации в этом сугубо личном мирке не требуется свертывания одних приложений в кнопки, отыскивания в taskbar других и т. д. Достаточно просто выбрать из меню новую "роль". "Общение" между мирами легко организовывается с помощью так называемых sticky-окон ("пришпиленных"), которые существуют на экранах всех "миров". Соответственно настоящий ОМ должен позволять "пришпиливать" любое окно по желанию пользователя.

Последний фрагмент нашего обсуждения на самом деле — главный. Но так как он требует достаточно высокой квалификации от пользователя, ему уготовано место "в тени". Речь пойдет о пригодности оконной системы к настройкам — по-настоящему тонким настройкам, а не к примитивному выбору стиля отображения обрамления окна или расположения интерфейсных элементов.

Мы пользуемся разными приложениями, представляющими для каждого из нас разную ценность. Соответственно действительно хороший и мощный ОМ должен позволять именно нам гибко управлять оконными "политиками" (фокусной моделью, видом обрамления, возможностью/невозможностью изменения размеров и положения, признаком "пришпиливания", расположением окон исключительно в пределах указанного экрана—ролевого "мира" и т. д.) для отдельных классов приложений. Это не просто "крутая фича" — это элемент культуры и удобства, кроме всего прочего оберегающий кисти наших рук от раннего туннельного синдрома.

К счастью приверженцев Windows, принятая в пользовательских ОС модель "ищите программу" срабатывает и позволяет устранить ряд врожденных недостатков ОМ этой ОС. Но радость от этого факта омрачается сопутствующими "болезнями" самой модели: мощный и функционально развитый ОМ WindowsBlind (www.windowsblind.com), устраняющий большинство из перечисленных недостатков, добавляет "всего лишь" два своих — он ненадежен в работе и не бесплатен (правда, не так уж и дорог — всего $20), а бесплатный LiteStep (www.litestep.com) не обладает свойством "аполитичности", имитируя пользовательскую модель ОС NextStep — безусловно удачную, но не единственную в природе.

В отличие от Windows абсолютно свободная от любых "политик" использования комбинация ОС Unix и графической подсистемы X Window предлагает несоизмеримо более удобные оконные менеджеры. Начнем с того, что реализаций ОМ — множество. Здесь существуют и свои "монстры", только перечисление возможностей которых заняло бы весь объем журнала, и свои "лилипуты", на первый взгляд ограничивающие функциональность до безобразного минимума. За это разнообразие (часто именуемое сегментацией GUI) ОС Unix подвергается массированной критике в прессе, а сам факт его существования уже объявлен чуть ли не главной причиной всех бед и неудач самой системы и компаний, пытающихся ее "одомашнить". Возможно, с "высоты полета" менеджера по сбыту все именно так и выглядит, но с точки зрения пользователя, проводящего ежедневно многие часы с любым воплощением ОС Unix, пресловутая "сегментация" оказывается… одним из самых серьезных достоинств, потому что она дает возможность выбора, в котором, как известно, и заключается одна из главных составляющих Свободы. А свобода — это всегда очень удобно, но и хлопотно, так как настоящая свобода требует знаний (хотя бы законов, определяющих права, обязанности и ответственность).

Оставив за пределами статьи неизбежные хлопоты, хочется остановиться на главной возможности комбинации ОС Unix/X Window, радикально отличающей способности этой системы в части оконного менеджмента от любой другой существующей ОС. Удивляет и тот факт, что эта возможность практически полностью обойдена вниманием, а программы, ее поддерживающие, непопулярны (можно сказать, — почти не известны) и не развиваются. Речь идет об адаптации двух главных концепций ОС Unix — скриптинга и сервисов-демонов — к задачам оконного менеджмента. Скриптинг фактически означает доступность перестройки поведенческих и визуальных особенностей ОМ без изменения низкоуровневого исполняемого программного кода с помощью "настроенного" на заданную целевую область специального интерпретируемого высокоуровневого языка программирования. Сервисы-демоны — это "невидимые" пользователю процессы, исполняющиеся в фоновом режиме и активизирующие те или иные действия. Например, древняя утилита xwit, которую можно отыскать в закоулках ftp-серверов Сети, позволяет с помощью простых и понятных команд из скриптов управлять положением окон на экранах, их размером, перемещать курсор и даже направлять из скрипта ввод в окно находящегося в фокусе приложения. Данная утилита подсказывает путь доведения удобства применения компьютера до почти идеального уровня (причем не в представлении кого-то, а именно для данного конкретного пользователя). А в сочетании с полиэкранными возможностями современных оконных менеджеров X Window xwit способствует и реализации концепции ролевого интерфейса (строящегося, к слову, на базе уже давно созданных приложений). Если же функции xwit (или аналогичной утилиты) использовать постоянно и прозрачно в сеансе работы (а не только при инициализации этого сеанса) с помощью демона оконного сервиса, не зависящего от используемого оконного менеджера, можно считать, что полученный гибрид является самим совершенством в маленьком мире ОМ.

Ассоциированные приложения, их ролевой выбор — термины, совершенно непонятные и, что более печально, недоступные в пользовательских ОС, в Unix/X Window имеют ярко выраженный смысл. Термин "редактирование" для одного типа данных (или файла) означает на самом деле абсолютно разные вещи в зависимости от выбранной пользователем роли. Если в определенный момент "я" выступает в роли "журналиста", то активация процесса "редактирование" для файла типа RTF (Rich Text Format) означает именно то, что она означает для журналиста — красивый и удобный текстовый редактор "с бантиками" в виде проверки правописания, форматирования таблиц, вставки рисунков. Но как только "я" изменяет роль на "Web-дизайнера", та же самая операция "редактирование" для того же самого файла означает автоматическое конвертирование RTF в HTML и активацию целого ряда ассоциированных приложений, окна которых расставляются на "своем" ролевом экране, на "своих" местах и курсор (фокус) автоматически помещается туда, куда нужно. Разве это не удобно и за возможность постоянной работы в таких условиях не стоит "заплатить" несколькими часами своего времени?

P. S., или Почему
я люблю ПК…

Несмотря на убогость архитектуры, чудовищную сегментацию аппаратных средств и стандартов, отвратительный дизайн и прочие малосущественные недостатки (болезненно и ощутимо выражающиеся только в денежном эквиваленте), автор этой статьи все-таки хочет сказать пару слов в защиту несчастного "обреченного" ПК. Именно эти дешевые универсальные компьютеры дают нам возможность хоть на время, проводимое за монитором, почувствовать себя Богом и творить свой мир для себя. И у нас всегда есть выбор в сотворении этого мира, надо только не забывать прописную истину: "трудно быть Богом". Но до чего же все-таки интересно.

Комментарий к иллюстрациям

Типичный сеанс работы автора на ПК, выполняющем роль рабочей станции (рис. 2—8) и попытка его воссоздания на "просто ПК" (рис. 1). К сожалению, выбор роли (рис. 2), удобная навигация в пространстве сокращенного представления окон (рис. 6), полиэкранность (рис.2, 4—8) с возможностью "пришпиливания" окон на все виртуальные экраны (окно броузера с рисунком летательного аппарата и эмулятор терминала в нижней части экрана) и установки их положения в "стековом порядке" — все это для пользователей "просто ПК" пока не доступно.

Рис. 1
Рис. 2
Рис. 3
Рис. 4
Рис. 5
Рис. 6
Рис. 7
Рис. 8

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: