Читать онлайн «Прикладные свободные программы и системы в школе». Страница 29

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

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

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

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

— возможности переназначения ввода-вывода и соединения программ каналами;

— философии «набора инструментов» (одна утилита — одна функция);

— наличия в оболочке механизма регулярных выражений.

По Вагнеру, по-настоящему успешным графическим интерфейсом («True UNIX GUI») будет интерфейс, предлагающий не менее целостную и последовательно реализованную концептуальную основу. Причем, предлагающий ее не только и не столько конечному пользователю, сколько разработчику, т.е. реализованный начиная с системы быстрой разработки (СБР, RAD). В упомянутой статье Вагнер рассматривает несколько кандидатов на роль универсальной формы представления информации в графической среде и рассуждает о том, какие принципы могли бы стать аналогами другим «китам», на которых покоится командно-строчный интерфейс.

На самом деле, существует целый ряд систем, в той или иной степени закладывающих основу «интерфейсов следующего поколения». К сожалению, ни одну из них нельзя назвать на сегодня массовой, кроме, возможно, языка описания интерфейса XUL, использованного в «Мозилла» (см. гл. 3), но и для XUL пока нет СБР.

В то время, как сама оконная система «Икс» много лет является фактическим отраслевым стандартом, лежащие «над» нею слои графической среды не стандартизованы.

Какую-либо классификацию графических сред дать затруднительно, однако самым грубым образом их можно разделить на «интегрированные» и «легкие».

Оборотной стороной интегрированности является достаточно высокая их требовательность к ресурсам. Комфортная работа с «КДЕ» или «Гном» «свежего разлива» начинается примерно от производительности, эквивалентной производительности 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), следует подумать об использовании такой техники в режиме графических терминалов или, по крайней мере, варианте запуска наиболее «тяжелых» прикладных программ на сервере.)

Следует оговорить также, что ограниченность аппаратных ресурсов не является единственным мотивом применения «легких» графических сред. Каждая графическая среда, интегрированная или легкая, обладает собственными уникальными особенностями, собственным стилем, и уместность пользования конкретной средой в значительной степени зависит от набора задач, решаемых на компьютере конкретным пользователям, и от его личных предпочтений.

Как уже говорилось, ключевой компонент графической платформы — Икс-сервер:

— захватывает оборудование,

— создает по запросу других программ (которые в этой терминологии называются X-клиентами) окна и

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

В «голой» среде, образуемой Икс-сервером без оконного менеджера, окно, выделяемое клиенту, является фиксированным: его геометрия (местоположение на экране и размер) задается при запуске клиента и сохраняется в течение всего сеанса работы с этим клиентом. Это вполне соответствует цели создания специализированных систем с графическим интерфейсом пользователя (таких, как мультимедийные киоски и т.п.), но совершенно недостаточно для универсального «настольного» применения.

При универсальном применении компьютера характерна поочередная работа с различными программами (иногда достаточно большим их количеством), причем пользователь может отрываться, допустим, от редактирования текста, чтобы поработать другой программой с иллюстрацией, прочитать почту или заглянуть на WWW-страницу, затем возвращаться к редактированию текста и т.д. Графическая операционная среда должна быть достаточно гибкой, чтобы допускать и поддерживать такой, «субъектно-ориентированный», а не ориентированный на строго последовательное выполнение предзаданных процедур, стиль работы.

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

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

Технически ограничение на изменение геометрии однажды выделенного окна преодолевается оконным менеджером за счет того, что ему в качестве окна выделяется весь экран.