Лишь один пример: сколько способов визуализировать перемещение окна вы знаете? Разработчики «Просвещения» придумали целых шесть, включая фантастический «полупрозрачный». Настройки и расширения Enlightenment можно объединять в «темы» (themes) и обмениваться ими.

Собственно, на этом функции оконного менеджера как такового и заканчиваются, а дальше Enlightenment вторгается во владения другого класса программ – менеджеров рабочего стола...

...Что демонстрирует отсутствие резкой границы между ними. Существует два подхода к тому, чтобы достроить оконную систему до полнофункциональной среды. Первый – добавить в «графический сэндвич» еще один слой – менеджер рабочего стола – работающий «поверх» оконного менеджера и использующий функциональность последнего. Этим путем идут команды разработчиков «ГНОМ» (см. раздел 2.17) и «КДЕ» (см. раздел 2.18).

Другой путь – «дотянуть» до полнофункциональной среды функциональность самого оконного менеджера, и им идет «Enlightenment» и ряд других проектов.

Чего нам не хватает до полнофункциональной среды? Менеджера программ и утилит. Так вот, в «Просвещении» есть и такая функциональность, доступная (по умолчанию) по щелчку на фоне левой кнопкой.

Комментировать здесь особо нечего: пункты меню позволяют запустить множество различных приложений, причем, кроме независимо разработанных, и целую пачку «эпплетов», поставляемых вместе с «Enlightenment». Альтернативный способ запуска – через «панель» – встроен в некоторые темы «Просвещения».

Откуда берутся такие ресурсы, как «виджеты» с их декором и способом поведения? Конечно, менеджер окон может содержать их в себе. Но такой подход не очень характерен для открытых систем, одним из принципов разработки которых является компонентность. Большинство развитых оконных менеджеров, менеджеров рабочего стола и «заточенных» под них приложений можно сгруппировать по библиотекам (toolkits), с опорой на которые они разработаны.

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

Фредерик Брукс еще в 1995 г., обсуждая основные процессы, произошедшие в программной отрасли за 20 предшествовавших лет, назвал в числе «наиболее впечатляющих явлений» «триумф интерфейса WIMP» [17, сс. 239-243] . В этом ставшем классическим четырехстраничном анализе (всем, интересующимся темой, крайне рекомендуется прочитать эти четыре страницы, а заодно – и всю книгу), Брукс:

производит декомпозицию самой идеи («диалог» с системой: объекты-«существительные» и действия-«глаголы»),

выделяет факторы, способствовавшие ее «триумфу» («концептуальная целостность через метафору» «рабочего стола»; эквивалентность клавиатурных команд пунктам меню, обеспечивающая постепенный переход от новичка к опытному пользователю; навязывание архитектуры через средства разработки),

называет ограничения метафоры «рабочего стола» («проблема двух курсоров»), а также

предрекает устаревание WIMP при внедрении речевого интерфейса («WIMP через поколение станет достоянием истории. Указание курсором останется способом задания существительных при управлении нашими компьютерами. Для выражения глаголов станет использоваться речь»).

Прошло еще пять лет, и мы можем отметить, что:

Проф. Брукс не заметил решения «проблемы двух курсоров» (а заодно – и непротиворечивой интеграции командной строки в графико-интерфейсное окружение) в конце восьмидесятых в Norton Commander (и сонме последователей этой замечательной программы на разных платформах (обзор см. в [15] . Проф. Безруков предложил для реализованного в Norton Commander интерфейса термин «ортодоксальный менеджер файлов» (OFM));

WIMP не думает устаревать, и скорее сам абсорбирует новые интерфейсные возможности (включая распознавание речи), чем будет вытеснен ими;

и, наконец, самое серьезное – это то, что «триумф WIMP» на сегодня выглядит не то чтобы менее бесспорным, а менее однозначным, все более походя на пресловутое «триумфальное шествие советской власти» по обессиленным Первой мировой войной частям Российской империи и ее окрестностей. Во многих прикладных областях попытки внедрения WIMP стали скорее частью проблемы пользовательского интерфейса, чем частью ее решения.

«Сплошной» же WIMP-среды и вовсе нет нигде, кроме встроенных/специализированных систем: в любом окружении, претендующем даже не на универсальность, а просто на широкую сферу применения, элементы WIMP сочетаются с элементами другой интерфейсной модели – командно-строчной – иногда более органично (OFM, AppleScript и т.п.), а чаще эклектично, противоречиво и с фатальным для производительности исходом (фрагменты «рваной» командной строки в «диалоговых окнах», разнообразные Wizards и «окна установки предпочтений»).

Если перечитать текст доклада, в котором идеи WIMP впервые были представлены широкой публике [16] , станет понятно, почему: модель WIMP предлагалась как средство непосредственного манипулирования конкретными объектами («взять это и положить туда», «изменить такое-то свойство того-то объекта», а не как средство формулирования абстрактных положений и команд («все ли файлы, лежащие в каталоге X, имеют формат Y?», «удалить все файлы, созданные до 01.01.2000 в которых упоминается Борис Ельцин» и т.п.). Соответственно, сделать WIMP-рабочее место для выполнения технических процедур, «рабского», неквалифицированного труда можно, а вот систему поддержки полноценной свободной практики – затруднительно.

Виктор Вагнер [18] противопоставляет «рыхлости» модели WIMP, пусть и целостной метафорически, концептуальную целостность командно-строчного интерфейса, основывающуюся на четырех принципах: