2.6 Триумф интерфейса над пользователем?
Косметических улучшений за тридцать лет существования парадигмы WIMP была придумана масса, а вот более или менее серьезных, при внимательном анализе, обнаруживается только два: интеграция звука (и превращение графической (визуальной) среды в сенсуальную) и начало эксплуатации концепции гиперссылок, в терминах которых можно переформулировать почти весь интерфейс.
Фредерик Брукс еще в 1995 г., обсуждая основные процессы, произошедшие в программной отрасли за 20 предшествовавших лет, назвал в числе «наиболее впечатляющих явлений» «триумф интерфейса WIMP»[77]. В этом ставшем классическим четырехстраничном анализе (всем, интересующимся темой, крайне рекомендуется прочитать эти четыре страницы, а заодно — и всю книгу), Брукс:
производит декомпозицию самой идеи («диалог» с системой: объекты-«существительные» и действия-«глаголы»),
выделяет факторы, способствовавшие ее «триумфу» («концептуальная целостность через метафору» «рабочего стола»; эквивалентность клавиатурных команд пунктам меню, обеспечивающая постепенный переход от новичка к опытному пользователю; навязывание архитектуры через средства разработки),
называет ограничения метафоры «рабочего стола» («проблема двух курсоров»), а также
предрекает устаревание WIMP при внедрении речевого интерфейса («WIMP через поколение станет достоянием истории. Указание курсором останется способом задания существительных при управлении нашими компьютерами. Для выражения глаголов станет использоваться речь»).
Прошло еще пять лет, и мы можем отметить, что:
Проф. Брукс не заметил решения «проблемы двух курсоров» (а заодно — и непротиворечивой интеграции командной строки в графико-интерфейсное окружение) в конце восьмидесятых в Norton Commander (и сонме последователей этой замечательной программы на разных платформах (обзор см. в[78]. Проф. Безруков предложил для реализованного в Norton Commander интерфейса термин «ортодоксальный менеджер файлов» (OFM));
WIMP не думает устаревать, и скорее сам абсорбирует новые интерфейсные возможности (включая распознавание речи), чем будет вытеснен ими;
и, наконец, самое серьезное — это то, что «триумф WIMP» на сегодня выглядит не то чтобы менее бесспорным, а менее однозначным, все более походя на пресловутое «триумфальное шествие советской власти» по обессиленным Первой мировой войной частям Российской империи и ее окрестностей. Во многих прикладных областях попытки внедрения WIMP стали скорее частью проблемы пользовательского интерфейса, чем частью ее решения.
«Сплошной» же WIMP-среды и вовсе нет нигде, кроме встроенных/специализированных систем: в любом окружении, претендующем даже не на универсальность, а просто на широкую сферу применения, элементы WIMP сочетаются с элементами другой интерфейсной модели — командно-строчной — иногда более органично (OFM, AppleScript и т.п.), а чаще эклектично, противоречиво и с фатальным для производительности исходом (фрагменты «рваной» командной строки в «диалоговых окнах», разнообразные Wizards и «окна установки предпочтений»).
Если перечитать текст доклада, в котором идеи WIMP впервые были представлены широкой публике[79], станет понятно, почему: модель WIMP предлагалась как средство непосредственного манипулирования конкретными объектами («взять это и положить туда», «изменить такое-то свойство того-то объекта», а не как средство формулирования абстрактных положений и команд («все ли файлы, лежащие в каталоге X, имеют формат Y?», «удалить все файлы, созданные до 01.01.2000 в которых упоминается Борис Ельцин» и т.п.). Соответственно, сделать WIMP-рабочее место для выполнения технических процедур, «рабского», неквалифицированного труда можно, а вот систему поддержки полноценной свободной практики — затруднительно.
Фредерик Брукс еще в 1995 г., обсуждая основные процессы, произошедшие в программной отрасли за 20 предшествовавших лет, назвал в числе «наиболее впечатляющих явлений» «триумф интерфейса WIMP»[77]. В этом ставшем классическим четырехстраничном анализе (всем, интересующимся темой, крайне рекомендуется прочитать эти четыре страницы, а заодно — и всю книгу), Брукс:
производит декомпозицию самой идеи («диалог» с системой: объекты-«существительные» и действия-«глаголы»),
выделяет факторы, способствовавшие ее «триумфу» («концептуальная целостность через метафору» «рабочего стола»; эквивалентность клавиатурных команд пунктам меню, обеспечивающая постепенный переход от новичка к опытному пользователю; навязывание архитектуры через средства разработки),
называет ограничения метафоры «рабочего стола» («проблема двух курсоров»), а также
предрекает устаревание WIMP при внедрении речевого интерфейса («WIMP через поколение станет достоянием истории. Указание курсором останется способом задания существительных при управлении нашими компьютерами. Для выражения глаголов станет использоваться речь»).
Прошло еще пять лет, и мы можем отметить, что:
Проф. Брукс не заметил решения «проблемы двух курсоров» (а заодно — и непротиворечивой интеграции командной строки в графико-интерфейсное окружение) в конце восьмидесятых в Norton Commander (и сонме последователей этой замечательной программы на разных платформах (обзор см. в[78]. Проф. Безруков предложил для реализованного в Norton Commander интерфейса термин «ортодоксальный менеджер файлов» (OFM));
WIMP не думает устаревать, и скорее сам абсорбирует новые интерфейсные возможности (включая распознавание речи), чем будет вытеснен ими;
и, наконец, самое серьезное — это то, что «триумф WIMP» на сегодня выглядит не то чтобы менее бесспорным, а менее однозначным, все более походя на пресловутое «триумфальное шествие советской власти» по обессиленным Первой мировой войной частям Российской империи и ее окрестностей. Во многих прикладных областях попытки внедрения WIMP стали скорее частью проблемы пользовательского интерфейса, чем частью ее решения.
«Сплошной» же WIMP-среды и вовсе нет нигде, кроме встроенных/специализированных систем: в любом окружении, претендующем даже не на универсальность, а просто на широкую сферу применения, элементы WIMP сочетаются с элементами другой интерфейсной модели — командно-строчной — иногда более органично (OFM, AppleScript и т.п.), а чаще эклектично, противоречиво и с фатальным для производительности исходом (фрагменты «рваной» командной строки в «диалоговых окнах», разнообразные Wizards и «окна установки предпочтений»).
Если перечитать текст доклада, в котором идеи WIMP впервые были представлены широкой публике[79], станет понятно, почему: модель WIMP предлагалась как средство непосредственного манипулирования конкретными объектами («взять это и положить туда», «изменить такое-то свойство того-то объекта», а не как средство формулирования абстрактных положений и команд («все ли файлы, лежащие в каталоге X, имеют формат Y?», «удалить все файлы, созданные до 01.01.2000 в которых упоминается Борис Ельцин» и т.п.). Соответственно, сделать WIMP-рабочее место для выполнения технических процедур, «рабского», неквалифицированного труда можно, а вот систему поддержки полноценной свободной практики — затруднительно.
2.7 От какого наследства нам не стоит отказываться?
Виктор Вагнер[80] противопоставляет «рыхлости» модели WIMP, пусть и целостной метафорически, концептуальную целостность командно-строчного интерфейса, основывающуюся на четырех принципах:
универсальности формы представления информации (текстовый файл, понимаемый как последовательность символов, некоторые из которых разделяют строки (записи), поля и слова);
— возможности переназначения ввода-вывода и соединения программ каналами;
— философии «набора инструментов» (одна утилита — одна функция);
— наличия в оболочке механизма регулярных выражений.
По Вагнеру, по-настоящему успешным графическим интерфейсом («True UNIX GUI») будет интерфейс, предлагающий не менее целостную и последовательно реализованную концептуальную основу. Причем, предлагающий ее не только и не столько конечному пользователю, сколько разработчику, т.е. реализованный начиная с системы быстрой разработки (СБР, RAD). В упомянутой статье Вагнер рассматривает несколько кандидатов на роль универсальной формы представления информации в графической среде и рассуждает о том, какие принципы могли бы стать аналогами другим «китам», на которых покоится командно-строчный интерфейс.
На самом деле, существует целый ряд систем, в той или иной степени закладывающих основу «интерфейсов следующего поколения». К сожалению, ни одну из них нельзя назвать на сегодня массовой, кроме, возможно, языка описания интерфейса XUL, использованного в «Мозилла» (см. гл. 3), но и для XUL пока нет СБР.
универсальности формы представления информации (текстовый файл, понимаемый как последовательность символов, некоторые из которых разделяют строки (записи), поля и слова);
— возможности переназначения ввода-вывода и соединения программ каналами;
— философии «набора инструментов» (одна утилита — одна функция);
— наличия в оболочке механизма регулярных выражений.
По Вагнеру, по-настоящему успешным графическим интерфейсом («True UNIX GUI») будет интерфейс, предлагающий не менее целостную и последовательно реализованную концептуальную основу. Причем, предлагающий ее не только и не столько конечному пользователю, сколько разработчику, т.е. реализованный начиная с системы быстрой разработки (СБР, RAD). В упомянутой статье Вагнер рассматривает несколько кандидатов на роль универсальной формы представления информации в графической среде и рассуждает о том, какие принципы могли бы стать аналогами другим «китам», на которых покоится командно-строчный интерфейс.
На самом деле, существует целый ряд систем, в той или иной степени закладывающих основу «интерфейсов следующего поколения». К сожалению, ни одну из них нельзя назвать на сегодня массовой, кроме, возможно, языка описания интерфейса XUL, использованного в «Мозилла» (см. гл. 3), но и для XUL пока нет СБР.
2.8 Зачем нужны «легкие» среды?
В то время, как сама оконная система «Икс» много лет является фактическим отраслевым стандартом, лежащие «над» нею слои графической среды не стандартизованы.
Какую-либо классификацию графических сред дать затруднительно, однако самым грубым образом их можно разделить на «интегрированные» и «легкие».
Оборотной стороной интегрированности является достаточно высокая их требовательность к ресурсам. Комфортная работа с «КДЕ» или «Гном» «свежего разлива» начинается примерно от производительности, эквивалентной производительности 800 МГц процессора Celeron, отказ от некоторых ресурсоемких свойств (анимация изменений в среде и т.п.) позволяет «снизить планку» примерно до 500 МГц при объеме оперативной памяти от 128 МБ. Разумеется, эти цифры даже ниже характерных для компьютеров «стартового уровня», поставляемых сегодня производителями, однако парк машин, находящихся в эксплутации, как в офисах, так дома и в школе, включает и компьютеры с более низкими характеристиками.
Так, в школе весьма желательно предоставить возможность работы в графической среде на менее мощных машинах. Здесь помогут «легкие» графические среды, представляющие собой оконные менеджеры с несколько расширенными возможностями (базовая и расширенная функциональность типичных оконных менеджеров описана ниже).
Обсуждаемые сегодня IceWB, BlackBox и fluxBox (а также чуть более требовательный к ресурсам WindowMaker)[63] позволяют достаточно комфортно работать с графикой на машинах производительностью (в эквиваленте Intel Pentium) примерно от 100 МГц и с памятью от 32М (текст одного из предыдущих разделов набирался в поезде, с одновременной «съемкой» изображений с его экрана графическим редактором «ГИМП» (см. главу 5) на ноутбуке с процессором Intel Pentium MMX 166 и ОЗУ объемом 64МБ).
Следует оговориться, что отказ от интегрированных графических сред не является «волшебной палочкой»: конкретные прикладные программы могут быть сами по себе достаточно требовательными к ресурсам. Так, на упомянутом ноутбуке запуск word-процессора «OpenWriter» занимает более минуты (хотя дальнейшая работа не сопряжена с существенными задержками). Кроме того, если прикладная программа изначально создана в ориентации на определенную интегрированную среду, она может интенсивно использовать соответствующие библиотеки, даже если запускается в «легкой» среде. Например, запуск программ из пакета KOffice в «легкой» среде, на самом деле, дает небольшой выигрыш по сравнению с его запуском из «родной» для него среды «КДЕ».
(Если необходимо задействовать имеющийся парк «слабой» техники для таких задач, а также, если необходимо сохранять в эксплуатации еще менее производительные машины (например, старшие модели IBM PC-совместимых компьютеров на базе процессоров Intel 486 или AMD 586 или «Макинтоши» на процессорах Motorola 68K), следует подумать об использовании такой техники в режиме графических терминалов или, по крайней мере, варианте запуска наиболее «тяжелых» прикладных программ на сервере.)
Следует оговорить также, что ограниченность аппаратных ресурсов не является единственным мотивом применения «легких» графических сред. Каждая графическая среда, интегрированная или легкая, обладает собственными уникальными особенностями, собственным стилем, и уместность пользования конкретной средой в значительной степени зависит от набора задач, решаемых на компьютере конкретным пользователям, и от его личных предпочтений.
Какую-либо классификацию графических сред дать затруднительно, однако самым грубым образом их можно разделить на «интегрированные» и «легкие».
Оборотной стороной интегрированности является достаточно высокая их требовательность к ресурсам. Комфортная работа с «КДЕ» или «Гном» «свежего разлива» начинается примерно от производительности, эквивалентной производительности 800 МГц процессора Celeron, отказ от некоторых ресурсоемких свойств (анимация изменений в среде и т.п.) позволяет «снизить планку» примерно до 500 МГц при объеме оперативной памяти от 128 МБ. Разумеется, эти цифры даже ниже характерных для компьютеров «стартового уровня», поставляемых сегодня производителями, однако парк машин, находящихся в эксплутации, как в офисах, так дома и в школе, включает и компьютеры с более низкими характеристиками.
Так, в школе весьма желательно предоставить возможность работы в графической среде на менее мощных машинах. Здесь помогут «легкие» графические среды, представляющие собой оконные менеджеры с несколько расширенными возможностями (базовая и расширенная функциональность типичных оконных менеджеров описана ниже).
Обсуждаемые сегодня IceWB, BlackBox и fluxBox (а также чуть более требовательный к ресурсам WindowMaker)[63] позволяют достаточно комфортно работать с графикой на машинах производительностью (в эквиваленте Intel Pentium) примерно от 100 МГц и с памятью от 32М (текст одного из предыдущих разделов набирался в поезде, с одновременной «съемкой» изображений с его экрана графическим редактором «ГИМП» (см. главу 5) на ноутбуке с процессором Intel Pentium MMX 166 и ОЗУ объемом 64МБ).
Следует оговориться, что отказ от интегрированных графических сред не является «волшебной палочкой»: конкретные прикладные программы могут быть сами по себе достаточно требовательными к ресурсам. Так, на упомянутом ноутбуке запуск word-процессора «OpenWriter» занимает более минуты (хотя дальнейшая работа не сопряжена с существенными задержками). Кроме того, если прикладная программа изначально создана в ориентации на определенную интегрированную среду, она может интенсивно использовать соответствующие библиотеки, даже если запускается в «легкой» среде. Например, запуск программ из пакета KOffice в «легкой» среде, на самом деле, дает небольшой выигрыш по сравнению с его запуском из «родной» для него среды «КДЕ».
(Если необходимо задействовать имеющийся парк «слабой» техники для таких задач, а также, если необходимо сохранять в эксплуатации еще менее производительные машины (например, старшие модели IBM PC-совместимых компьютеров на базе процессоров Intel 486 или AMD 586 или «Макинтоши» на процессорах Motorola 68K), следует подумать об использовании такой техники в режиме графических терминалов или, по крайней мере, варианте запуска наиболее «тяжелых» прикладных программ на сервере.)
Следует оговорить также, что ограниченность аппаратных ресурсов не является единственным мотивом применения «легких» графических сред. Каждая графическая среда, интегрированная или легкая, обладает собственными уникальными особенностями, собственным стилем, и уместность пользования конкретной средой в значительной степени зависит от набора задач, решаемых на компьютере конкретным пользователям, и от его личных предпочтений.
2.9 Базовая функциональность оконного менеджера
Как уже говорилось, ключевой компонент графической платформы — Икс-сервер:
— захватывает оборудование,
— создает по запросу других программ (которые в этой терминологии называются X-клиентами) окна и
— предоставляет другим программам возможность работы в окнах, то есть вывода информации в эти окна и обработки сигналов от устройств ввода (клавиатуры и «мыши» или другого координатного устройства), когда окно, назначенное программе, является активным. Предоставление ресурсов возможно в том числе и через сеть, когда клиент и сервер работают на разных компьютерах (узлах).
В «голой» среде, образуемой Икс-сервером без оконного менеджера, окно, выделяемое клиенту, является фиксированным: его геометрия (местоположение на экране и размер) задается при запуске клиента и сохраняется в течение всего сеанса работы с этим клиентом. Это вполне соответствует цели создания специализированных систем с графическим интерфейсом пользователя (таких, как мультимедийные киоски и т.п.), но совершенно недостаточно для универсального «настольного» применения.
При универсальном применении компьютера характерна поочередная работа с различными программами (иногда достаточно большим их количеством), причем пользователь может отрываться, допустим, от редактирования текста, чтобы поработать другой программой с иллюстрацией, прочитать почту или заглянуть на WWW-страницу, затем возвращаться к редактированию текста и т.д. Графическая операционная среда должна быть достаточно гибкой, чтобы допускать и поддерживать такой, «субъектно-ориентированный», а не ориентированный на строго последовательное выполнение предзаданных процедур, стиль работы.
В частности, должно поддерживаться управление (с помощью клавиатуры или «мыши») окнами, т.е. возможность изменять «на лету» их геометрию (положение и размеры), а также (обычно не относимое к геометрии) положение в воображаемой «стопке» окон, т.е. определение того, какое из окон будет «верхним» (видимым полностью), если окна перекрывают друг друга на плоскости экрана.
Управление окнами и составляет базовую функциональность оконного менеджера (устоявшийся термин window manager, относящийся к этому классу программ, будет передаваться далее словосочетанием-калькой «оконный менеджер», которое, впрочем, не представляется особенно удачным, так же, как и встречающиеся в литературе «менеджер окон» и «администратор окон»).
Технически ограничение на изменение геометрии однажды выделенного окна преодолевается оконным менеджером за счет того, что ему в качестве окна выделяется весь экран.
Прикладным программам, таким образом, выделяются далее уже не окна собственно X, а окна оконного менеджера. Для них это совершенно прозрачно, хотя желательно, чтобы программа была достаточно «сообразительной», чтобы изменить свое поведение при изменении размеров выделенного ей окна «на лету» (изменение положения окна в подавляющем большинстве случаев ничего от клиента не требует), это справедливо для большинства, но не для всех программ (в частности, этого не «умеют» многие старые программы и некоторые компьютерные игры).
В свою очередь, и оконный менеджер может быть достаточно «умен», чтобы понять, что программа не реагирует на изменение геометрии, и заблокировать возможность изменения размеров окна пользователем (чтобы он не оказался в ситуации, когда ему видна лишь часть области вывода программы или наоборот, часть окна прикладной программы пуста). Однако такое решение может привести к весьма дискомфортным ситуациям (например, если при запуске программы ее окно оказывается больше экрана)[64].
— захватывает оборудование,
— создает по запросу других программ (которые в этой терминологии называются X-клиентами) окна и
— предоставляет другим программам возможность работы в окнах, то есть вывода информации в эти окна и обработки сигналов от устройств ввода (клавиатуры и «мыши» или другого координатного устройства), когда окно, назначенное программе, является активным. Предоставление ресурсов возможно в том числе и через сеть, когда клиент и сервер работают на разных компьютерах (узлах).
В «голой» среде, образуемой Икс-сервером без оконного менеджера, окно, выделяемое клиенту, является фиксированным: его геометрия (местоположение на экране и размер) задается при запуске клиента и сохраняется в течение всего сеанса работы с этим клиентом. Это вполне соответствует цели создания специализированных систем с графическим интерфейсом пользователя (таких, как мультимедийные киоски и т.п.), но совершенно недостаточно для универсального «настольного» применения.
При универсальном применении компьютера характерна поочередная работа с различными программами (иногда достаточно большим их количеством), причем пользователь может отрываться, допустим, от редактирования текста, чтобы поработать другой программой с иллюстрацией, прочитать почту или заглянуть на WWW-страницу, затем возвращаться к редактированию текста и т.д. Графическая операционная среда должна быть достаточно гибкой, чтобы допускать и поддерживать такой, «субъектно-ориентированный», а не ориентированный на строго последовательное выполнение предзаданных процедур, стиль работы.
В частности, должно поддерживаться управление (с помощью клавиатуры или «мыши») окнами, т.е. возможность изменять «на лету» их геометрию (положение и размеры), а также (обычно не относимое к геометрии) положение в воображаемой «стопке» окон, т.е. определение того, какое из окон будет «верхним» (видимым полностью), если окна перекрывают друг друга на плоскости экрана.
Управление окнами и составляет базовую функциональность оконного менеджера (устоявшийся термин window manager, относящийся к этому классу программ, будет передаваться далее словосочетанием-калькой «оконный менеджер», которое, впрочем, не представляется особенно удачным, так же, как и встречающиеся в литературе «менеджер окон» и «администратор окон»).
Технически ограничение на изменение геометрии однажды выделенного окна преодолевается оконным менеджером за счет того, что ему в качестве окна выделяется весь экран.
Прикладным программам, таким образом, выделяются далее уже не окна собственно X, а окна оконного менеджера. Для них это совершенно прозрачно, хотя желательно, чтобы программа была достаточно «сообразительной», чтобы изменить свое поведение при изменении размеров выделенного ей окна «на лету» (изменение положения окна в подавляющем большинстве случаев ничего от клиента не требует), это справедливо для большинства, но не для всех программ (в частности, этого не «умеют» многие старые программы и некоторые компьютерные игры).
В свою очередь, и оконный менеджер может быть достаточно «умен», чтобы понять, что программа не реагирует на изменение геометрии, и заблокировать возможность изменения размеров окна пользователем (чтобы он не оказался в ситуации, когда ему видна лишь часть области вывода программы или наоборот, часть окна прикладной программы пуста). Однако такое решение может привести к весьма дискомфортным ситуациям (например, если при запуске программы ее окно оказывается больше экрана)[64].
2.10 «Виджеты»
Базовая (а также расширенная) функциональность оконных менеджеров доступна пользователю прежде всего за счет введения в интерфейс так называемых «виджетов» (widgets = window gadgets, «оконные приспособления») — таких визуальных элементов, как рамки, кнопки, меню и пр., которые служат «органами управления» окна. Технически виджеты представляют собой отдельные окна (в терминах оконной системы «Икс»), примыкающие к окну прикладной программы и, как правило, перемещающиеся вместе с ним.
В пользовательской перспективе виджеты, составляющие обрамление окна, часто воспринимаются как его часть. Однако не следует забывать, что внутри окна (содержимым которого управляет прикладная программа) зачастую тоже есть свои виджеты: кнопки, полосы прокрутки, переключатели, меню и т.п. В общем случае, используемые оконным менеджером и прикладной программой библиотеки виджетов могут и не совпадать.
Обрамление окна обычно включает:
рамку, окружающую окно. При «буксировке» рамки мышью окно изменяет свой размер. Иногда для изменения размера окна предназначены только выделенные «уголки» рамки, представляющие собою отдельные виджеты;
полосу заголовка, часто совпадающую с одной из (обычно, верхней) сторон рамки. Полоса заголовка может содержать название программы, команду, ее запустившую, или другую информацию, специфичную для окна. При «буксировке» полосы заголовка перемещается все окно. Со «щелчками» различными кнопками мыши на полосе заголовка также могут быть связаны различные действия по управлению окнами;
кнопки управления окном. Часто вынесенные на полосу заголовка или в другое место рамки кнопки позволяют выполнить с ним такие действия, как закрытие (часто сопровождающееся выходом из программы, открывшей окно), максимизация (разворачивание окна на весь экран), минимизация/сворачивание (см. ниже расширенную функциональность), вызов меню управления окном, которое может содержать весьма обширный репертуар других действий.
Детали реализации обрамления окна могут быть весьма различными в зависимости от конкретного оконного менеджера и его настроек.
В пользовательской перспективе виджеты, составляющие обрамление окна, часто воспринимаются как его часть. Однако не следует забывать, что внутри окна (содержимым которого управляет прикладная программа) зачастую тоже есть свои виджеты: кнопки, полосы прокрутки, переключатели, меню и т.п. В общем случае, используемые оконным менеджером и прикладной программой библиотеки виджетов могут и не совпадать.
Рис. 2-8
(Зачастую при проектировании выдвигается требование единства стиля органов управления и согласованного управления изменением этого стиля (например, для настройки среды для пользователя с ограниченными возможностями: со слабым зрением, нарушением моторики и т.п.), и в этом сильно выигрывают интегрированные графические среды «Гном» и «КДЕ», используемые совместно с прикладными программами, основанными на тех же графических библиотеках и наследующими те же настройки. Однако на практике ограничиться набором программ, основанных на одной библиотеке графических примитивов, бывает трудно, поэтому разумно познакомить учеников с особенностями по крайней мере самых распространенных из них.)Обрамление окна обычно включает:
рамку, окружающую окно. При «буксировке» рамки мышью окно изменяет свой размер. Иногда для изменения размера окна предназначены только выделенные «уголки» рамки, представляющие собою отдельные виджеты;
полосу заголовка, часто совпадающую с одной из (обычно, верхней) сторон рамки. Полоса заголовка может содержать название программы, команду, ее запустившую, или другую информацию, специфичную для окна. При «буксировке» полосы заголовка перемещается все окно. Со «щелчками» различными кнопками мыши на полосе заголовка также могут быть связаны различные действия по управлению окнами;
кнопки управления окном. Часто вынесенные на полосу заголовка или в другое место рамки кнопки позволяют выполнить с ним такие действия, как закрытие (часто сопровождающееся выходом из программы, открывшей окно), максимизация (разворачивание окна на весь экран), минимизация/сворачивание (см. ниже расширенную функциональность), вызов меню управления окном, которое может содержать весьма обширный репертуар других действий.
Детали реализации обрамления окна могут быть весьма различными в зависимости от конкретного оконного менеджера и его настроек.
2.11 Расширенная функциональность оконного менеджера
Собственно, перечисленными функциями оконный менеджер, предназначенный для работы в составе интегрированной операционной среды, может и ограничиться. При использовании же в качестве операционной графической среды самого оконного менеджера, крайне полезной может оказаться его расширенная функциональность. К ней можно отнести:
минимизацию/сворачивание окон и управление свернутыми окнами. Работа на «столе», «захламленном» десятком различных окон, может быть дискомфортной, и крайне полезна возможность «свернуть» или «минимизировать» окно со временно неиспользуемой программой. Для того, чтобы средствами графической среды можно было окно затем развернуть, оно и в свернутом состоянии должно каким-то образом визуализироваться. Существует несколько относительно распространенных способов визуализации свернутых окон. Например, «на столе» может оставаться полоса заголовка свернутого окна, по щелчку на которой оно вновь разворачивается. Свернутым окнам могут соответствовать пиктограммы («иконки», «значки») на поверхности «рабочего стола» или в специально отведенном для этого окне («панели управления»). Свернутые окна могут визуализироваться как пункты общего или специального меню (см. ниже);
управление несколькими «столами». Практика показывает, что для многих продвинутых пользователей, для которых освоение стандартных систем следует за освоением специфически персонально-компьютерных, именно возможность работать на нескольких «столах» оказывается первым «убойным приложением» оконной системы «Икс». Действительно, переключение между виртуальными «столами» позволяет организовать комфортную работу со множеством программ даже на мониторах с относительно низким разрешением (1024х728, 800х600) и физическими размерами (17, 15-дюймовыми). В иных условиях комфортность работы существенно снизилась бы, или настоятельной необходимостью стало бы приобретение более крупного и емкого монитора (что зачастую влечет за собой необходимость смены графической карты и прочих недешевых мероприятий). Все современные оконные менеджеры поддерживают виртуальные столы, правда называются эти сущности в них по-разному: «столами», «рабочими областями» или «экранами». До предела (чтобы не сказать, до абсурда) эта функциональность развита в оконном менеджере Enlightenment, упоминавшемся в одном из предшествующих разделов: E позволяет организовать до 64 «экранов» на «рабочем столе», при этом «рабочих столов» также может быть более одного (точнее, до 32). Трудно представить, зачем может понадобиться две тысячи с лишним отдельных экранов (как правило, четырех экранов хватает с избытком для любых практических задач), однако возможности приема демонстрируются этим «в полный рост»;
быстрый запуск команд. Возможность быстрого запуска предуготовленных команд обычно ассоциируется с общим меню, вызываемым «щелчком» на особом виджете, не связанном с прикладными окнами, или в свободной от прикладных окон области экрана;
возможности настройки «поведения» и внешего вида среды. «Поведение» (реакция отдельных виджетов на операции с ними, модель фокусировки (связывание ввода с клавиатуры и «мыши» с теми или иными программами) и т.п.) и внешний вид оформления окон, а также наличие на экране «общих» виджетов, не связанных с конкретными прикладными окнами, «обои» и т.п. могут варьировать в очень широких пределах. Иногда возможности такой настройки считают некими «архитектурными излишествами», однако более взвешенной является точка зрения, согласно которой в хорошем визуальном дизайне (так же, как и в хорошей архитектуре) ничто не является излишеством. В частности, в школе программы эксплуатируются на широком спектре оборудования с весьма разными характеристиками и разного качества, причем используются они широким кругом людей с различными психофизическими особенностями, как в пределах нормы, так и связанных со здоровьем, и игнорировать возможности настройки нельзя даже уже исходя из гигиенических соображений.
минимизацию/сворачивание окон и управление свернутыми окнами. Работа на «столе», «захламленном» десятком различных окон, может быть дискомфортной, и крайне полезна возможность «свернуть» или «минимизировать» окно со временно неиспользуемой программой. Для того, чтобы средствами графической среды можно было окно затем развернуть, оно и в свернутом состоянии должно каким-то образом визуализироваться. Существует несколько относительно распространенных способов визуализации свернутых окон. Например, «на столе» может оставаться полоса заголовка свернутого окна, по щелчку на которой оно вновь разворачивается. Свернутым окнам могут соответствовать пиктограммы («иконки», «значки») на поверхности «рабочего стола» или в специально отведенном для этого окне («панели управления»). Свернутые окна могут визуализироваться как пункты общего или специального меню (см. ниже);
управление несколькими «столами». Практика показывает, что для многих продвинутых пользователей, для которых освоение стандартных систем следует за освоением специфически персонально-компьютерных, именно возможность работать на нескольких «столах» оказывается первым «убойным приложением» оконной системы «Икс». Действительно, переключение между виртуальными «столами» позволяет организовать комфортную работу со множеством программ даже на мониторах с относительно низким разрешением (1024х728, 800х600) и физическими размерами (17, 15-дюймовыми). В иных условиях комфортность работы существенно снизилась бы, или настоятельной необходимостью стало бы приобретение более крупного и емкого монитора (что зачастую влечет за собой необходимость смены графической карты и прочих недешевых мероприятий). Все современные оконные менеджеры поддерживают виртуальные столы, правда называются эти сущности в них по-разному: «столами», «рабочими областями» или «экранами». До предела (чтобы не сказать, до абсурда) эта функциональность развита в оконном менеджере Enlightenment, упоминавшемся в одном из предшествующих разделов: E позволяет организовать до 64 «экранов» на «рабочем столе», при этом «рабочих столов» также может быть более одного (точнее, до 32). Трудно представить, зачем может понадобиться две тысячи с лишним отдельных экранов (как правило, четырех экранов хватает с избытком для любых практических задач), однако возможности приема демонстрируются этим «в полный рост»;
быстрый запуск команд. Возможность быстрого запуска предуготовленных команд обычно ассоциируется с общим меню, вызываемым «щелчком» на особом виджете, не связанном с прикладными окнами, или в свободной от прикладных окон области экрана;
возможности настройки «поведения» и внешего вида среды. «Поведение» (реакция отдельных виджетов на операции с ними, модель фокусировки (связывание ввода с клавиатуры и «мыши» с теми или иными программами) и т.п.) и внешний вид оформления окон, а также наличие на экране «общих» виджетов, не связанных с конкретными прикладными окнами, «обои» и т.п. могут варьировать в очень широких пределах. Иногда возможности такой настройки считают некими «архитектурными излишествами», однако более взвешенной является точка зрения, согласно которой в хорошем визуальном дизайне (так же, как и в хорошей архитектуре) ничто не является излишеством. В частности, в школе программы эксплуатируются на широком спектре оборудования с весьма разными характеристиками и разного качества, причем используются они широким кругом людей с различными психофизическими особенностями, как в пределах нормы, так и связанных со здоровьем, и игнорировать возможности настройки нельзя даже уже исходя из гигиенических соображений.
* * *
Выше при характеристике тех или иных (предположительно, общих) характеристик оконных менеджеров чаще обычного употреблялись слова «обычно», «как правило», «может» и т.п. Это связано с чрезвычайным разнообразием решений на базе распространенных оконных менеджеров. Ниже самые распространенные из них характеризуются более подробно и определенно.
2.12 Оконные менеджеры «BlackBox» и «FluxBox»
Рис. 2-9
«BlackBox» («BB») — один из самых компактных, «минималистичных» и быстродействующих оконных менеджеров. Он позволяет эффективно организовать работу на «рабочем столе», не «захламляя» его ненужными ссылками и не расходуя экранное пространство на отображение громоздких элементов оформления.Наряду с базовой функциональностью, «BB» предоставляет (факультативно) панель, содержащую кнопки переключения между «рабочими столами» (по умолчанию их четыре) и заголовки открытых окон. Общее меню вызывается «щелчком» правой кнопкой «мыши» на свободном от окон месте «стола». Меню (или любое из вложенных в него меню) «щелчком» по заголовку может быть превращено в окно, остающееся на экране до явного его закрытия щелчком на соответствующей кнопке.
По умолчанию на полосе заголовка каждого окна присутствуют кнопки сворачивания (сворачивание можно выполнить также двойным «щелчком» на самом заголовке), максимизации и закрытия окна. Свернутое окно присутствует на экране в виде полосы заголовка, развернуть его можно повторным двойным «щелчком» на полосе заголовка или из меню Workspaces («рабочие пространства»), доступного по «щелчку» средней кнопкой мыши на свободном от окон месте «стола». Это же меню позволяет перейти на другой «стол», добавить или удалить «стол» из рабочего пространства.
«BB» поддерживает различные модели фокусировки ввода. «Click to focus» («фокусировка по щелчку») позволяет реализовать стиль работы, привычный для пользователей «Гном», «КДЕ» или «Майкрософт Уиндоуз»: окно становится активным (принимающим текущий ввод с клавиатуры и от «мыши») после «щелчка» на нем. Активное окно автоматически становится «верхним» (видимым полностью, даже если оно частично перекрывается с другими окнами). Модель «Sloppy focus» («небрежная фокусировка») предполагает активизацию окна при попадании на него курсора мыши (окно при этом не «всплывает» автоматически наверх).
Наряду с панелью и конвертируемыми в дополнительные окна-«панели» меню, «BB» реализует еще один автономный виджет — так называемую «щель» (Slit). «Щель» располагается на краю видимого экрана и может содержать маленькие (без обрамлений) окна специализированных программок (их существует около десяти), индицирующих какие-либо состояния среды или позволяющих быстро выполнить часто исполняемые действия.
На основе «BB» созданы два более развитых оконных менеджера — «OpenBox» и более популярный «FluxBox».
«Наиболее характерная особенность „Fluxbox“ — реализация закладок (tabs) в контексте рабочего стола. Если закладки в браузере позволяют одновременно открыть несколько страниц в одном окне, то закладки fluxbox позволяют удобно сгруппировать несколько окон на столе. Все окна в группе имеют одинаковые размеры и расположены строго одно под другим. Для переключения на какое-либо из них достаточно навести курсором мыши или щелкнуть (в зависимости от настроек) по соответствующей закладке. К примеру, мне приходится работать с несколькими различными почтовыми клиентами. Совместив их в одну группу, я могу легко переключаться между ними и при этом я всегда знаю, где расположено каждое окно. На словах объяснить преимущества этого оригинального подхода не очень легко, но после нескольких дней практического использования, становится трудно без него обходиться: к хорошему привыкаешь быстро.»
Внешний вид «BB», «FluxBox» и «OpenBox» легко настраивается с помощью механизма «тем» рабочих столов.
2.13 Оконный менеджер «WindowMaker»
