Ресурсы, X Window и ООП

(«Открытые системы», Лето 1994. стр. 67-72)

 

С. Трифонов

НИИСИ РАН, Москва

info@osp.msk.rи

 

 

Так получилось, что автор этих строк практически одновременно постигал премудрости Объектно-Ориентированного Программирования (ООП) на языке C++ и интерфейса X Window в среде Unix. Вместе с этим он овладел и активно распространяющимся профессиональным диалектом, которого пугаются "настоящие программисты" и в котором ключевыми словами являются "объект", "класс", "метод" и "событие". Бесконечные просторы для совершенствования и дискуссий открылись перед автором, но... К досаде автора, поначалу мало кто из "объектно-ориентированных" собеседников понимал одно словечко из его лексикона -"ресурсы". По прошествии некоторого времени слово стали воспринимать почти все, но ... неправильно. То есть правильно, но не полностью. Вернее, полностью, но не до конца.

 

 

X Window как объектно-ориентированная система

 

В X Window есть все перечисленные термины. Механизмы, при­меняемые в этой системе, воплощают объектную идеологию. По­клонников других систем интерфейса - любителей Макинтошей и почитателей MS Window - этим утверждением, вроде бы, не удивить. Действительно, в их системах те же принципы и механизмы. Однако, отличия есть. Во многом они связаны с механизмом ресурсов, в X Window существенно более гибким и универсальным. Содержатель­ным является даже автономное использование ресурсов, без осталь­ных частей.

Автор надеется, что рано или поздно понятие "ресурсы" (или его функциональный эквивалент) обретет свое достойное место в объ­ектно-ориентируемой технологии разработки программ. Об этом и написана данная статья. Ее первая часть посвящена самой системе X Window. Во второй части будут обсуждаться механизмы, возникаю­щие при реализации идеи ресурсов.

Технические детали программных продуктов по возможности бу­дут опускаться:, их можно найти в обширной литературе, посвящен-  . ной как X Window, так и ООП+ООП (Объектно-Ориентируемое Проектирование +' Программирование, OOD+OOP).

Система X Window - это огромное здание со сложной архитектурой, ходами-переходами, крышами, анфиладами и кариатидами. Что­бы разглядеть в этом хозяйстве ресурсы, нам придется нарисовать не­сколько планов: сначала общий вид, затем более подробно некоторую часть здания и уже после этого будет видно, где здесь "ресурсы".... Итак, начнем

 

Общий вид с высоты птичьего полета

 

X Window - графическая оконная система, разработанная изна­чально в расчете на построение интерфейса распределенных прило­жений, исполняющихся на сети разнородных рабочих UNIX-стан­ций. Основные архитектурные элементы, обеспечивающие сетевую прозрачность. - это Х-сервер и Х-клиент.

В зависимости от конфигурации, под Х-сервером могут подразу­меваться процесс, группа  процессов или отдельный специализиро­ванный компьютер. Под процессом подразумевается процесс в операционной системе UNIX. Существуют, впрочем, адаптации Х-Window на другие, естественно, многозадачные операци­онные системы. Там Х-сервер - это процесс другой опера­ционной системы. Самостоятельный компьютер, отождест­вляемый с Х-сервером, называется X-терминалом, но об этом позже.

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

Между Х-сервером и его клиентом существует проме­жуточная инстанция, Х-протокол. Это строгие и четкие спецификации на то, что сервер может послать клиенту, а что - клиент серверу. Механизм передачи данных между X-сервером и Х-клиентом может быть произвольным.

Вот так и рождается модульность и объектность.

Различные Х-серверы решают совершенно одинаковый комплект задач, оговоренный Х-протоколом, но на различ­ной аппаратуре; если же аппаратура не в состоянии решить некоторой специальной задачи, в Х-протоколе предусмот­рена возможность цивилизованного отказа от ее выполне­ния. В результате, Х-сервер, и только он, обязан учитывать особенности аппаратного уровня.

Различные инстанции решают задачу поддержки X-протокола: в рамках одного компьютера, одной комнаты, либо глобальной спутниковой связи. Любая программа, поддерживающая сравнительно небольшой Х-протокол, годится для работы. Ни сервер, ни клиент не обязаны знать, транспортный протокол какого стека используется: TCP/IP, SPX или OSI.

Наконец, Х-клиент не обязан вникать ни в какие аппа­ратные проблемы и занимается напрямую обслуживанием пользователя, эффективностью и комфортом его работы. Клиенту предоставляется также возможность связываться с другими клиентами, "бегущими" на том же сервере, чем, впрочем, они могут и не пользоваться.

Достоинства этой модели многочисленны. Вот некото­рые из них:

1.  Разделение функций облегчает отладку модулей, что делает сравнительно легкой адаптацию X Window на но­вую аппаратуру.

2. Для процессов, называющихся Х-сервер и Х-клиент, совершенно не важно, работают ли они на одном компьюте­ре или на разных, в одной ли комнате находятся эти два компьютера или связаны по международной сети. Если связь между компьютерами достаточно высока и надежна, никаких неприятностей не возникнет, даже если разработ­чики программы-клиента совершенно не задумывались о возможности использования своей программы на другом конце света. В то же время один клиент может работать од­новременно с несколькими серверами.

3.  Относительная независимость работы Х-клиентов от варианта Х-сервера.

Исключение составляют проблемы бедности аппарату­ры: как "никакие связи не помогут сделать ножку маленькой, а душу - оолыпоп", гак никто не см<),кет нарисовать красивую радугу на черно-белом терминале либо целиком вместить подробную карту города Москвы в экран 200 на 200 точек.

4.  Равноправность и независимость друг от друга всех Х-клиентов. Впрочем, это свойство - общее для любых про­цессов ОС UNIX. Когда в одном из процессов происходит ошибка, другие процессы этого не замечают (если, конечно, два процесса не взаимодействуют явно). Отладка Х-клиен­тов осуществляется с применением самых стандартных средств.

5. Процессы Х-сервера и поддержки Х-протокола явля­ются "рабами лампы": они выполняют набор строго огово­ренных функций, наделены интеллектом, которого хватает ровно на эти функции, и не имеют дурной привычки вме­шиваться в логику работы клиентов нерегламентированным образом (хотя бы и с самыми хорошими намерениями, как это принято, например, в MS Windows).

Как правило, в начале сеанса работы в X Window запу­скается некоторый специальный клиент, менеджер окон. Различных реализаций этого клиента довольно много (за­пускают в сеансе только один!), и решают они следующую задачу: расположить окна других Х-клиентов на экране терминала способом, удобным пользователю, окружить для этого окна клиентов приличествующим образом (рамка, за­головок и пр.). Довольно часто эти менеджеры также пре­доставляют ряд полезных возможностей общего плана (на­пример, удалить какое-нибудь окно). Каждый менеджер оформляет окружение окон в своем стиле, добиваясь (или пытаясь добиться) зрительной гармонии на графическом экране. Менеджер не является привилегированным про­цессом, он, скорее, дежурный у классной доски. За исклю­чением изменения размеров и местоположения окна на эк­ране (а к этому в любой оконной системе принято отно­ситься как к должному), никаких попыток вмешаться в ло­гику работы других Х-клиентов менеджер не делает.

И, наконец, последний объект, видимый с такой высо­ты, - X-терминал. Это некоторое аппаратное средство, включающее процессор и графический терминал, специ­ально предназначенное для выполнения задачи Х-сервера. Другими словами, в конфигурации с X-терминалом Х-сер­вер, как процесс, отсутствует, а реализующий Х-протокол модуль одной стороной "прикреплен" непосредственно к аппаратному средству. С точки зрения Х-клиентов, никако­го интереса такие "терминалы" не представляют. С точки зрения Х-пользователей, интерес большой - такая специа­лизированная конфигурация обеспечивает эффективную работу с графикой и совершенно бесполезна для примене­ний, не вписывающихся в рамки Х-протокола (в доступные сейчас версии Х-протокола не входит поддержка, напри­мер, средств анимации).

 

XLib, или о чем разговаривают сервер и клиенты

 

Самый нижний уровень программирования Х-клиентов обеспечивается библиотекой функций XLib. Задача этой библиотеки - предоставить С-интерфейс работы с Х-серве­ром. В библиотеке масса различных функций, а ее описание - это солидный том документации. Если быть запредельно кратким, надо сформулировать следующие постулаты:

1. Х-клиент связан с сервером и с остальными клиента­ми двумя видами связи: с помощью одного вида связи кли­ент передает серверу инструкции, что и как отрисовывать в окнах, с помощью другого вида - получает сообщения о со­бытиях, происходящих в процессе работы X Window. Кли­ент в состоянии породить и переслать кому-нибудь свое собственное сообщение. Этот механизм применяется не ча­сто, но иногда оказывается весьма эффективным.

2.  Для своей работы Х-клиент просит Х-сервер выде­лить для него ресурсы. (Это еще не те ресурсы, о которых пишется статья, а их омоним. К сожалению, в X Window од­но и то же слово используется в двух разных смыслах.) Под этим понимается довольно много различных объектов: ок­на, графические контексты, шрифты и прочее.

Всем объектам-ресурсам, выделяемым сервером, присва­иваются уникальные численные идентификаторы, по кото­рым и происходит адресация объектов. Параметры объектов-ресурсов клиент потом может многократно менять. По окон­чании работы с ресурсами клиенту полезно их освободить. Выполняемые сервером инструкции устроены так, что без специально выделенных ресурсов ничего сделать нельзя. На­пример, функция из XLib, предназначенная для изображения отрезка, требует в качестве параметров не только координаты отрезка, но и идентификатор дисплея, окно, где будет изобра­жаться отрезок, и графический контекст изображения (имен­но он содержит информацию о свойствах отрезка: его толщи­не, цвете и многих других параметрах).

3.  Окна на экране образуют иерархическую структуру окон, вложенных в головное окно, причем сколь угодно вы­сокого уровня. Каждое окно имеет свою систему коорди­нат, а часть окна, не умещающаяся в границы родительско­го окна, невидима на экране.

4.  При движении мыши по экрану, нажатии клавиш на клавиатуре, необходимости перерисовки области окна и прочих событиях X Window создает сообщение об этом и кладет его в очередь событий. Каждое сообщение адресова­но конкретному окну. Х-клиент, пользуясь функциями XLib, должен регулярно выбирать из очереди сообщения, адресованные его окнам, и обрабатывать их. Так клиент ре­агирует на действия пользователя.

Итак, с одной стороны, XLib поддерживает в достаточ­но объектном стиле отображение содержимого окон, а с другой - настраивает программиста на создание событий-но-управляемых (event-driven) приложений - также типич­но объектно-ориентированная идея.

Здесь можно было бы поставить точку. X Window, как низкоуровневая и в то же время универсальная среда, опит сана. Но оказывается, что тут-то как раз и начинается новая жизнь, которой живет большинство Х-клиентов. Ее суть - управление сложными данными по классической объект­но-ориентированной схеме.

 

 

Ящик с инструментами для Х-про-граммирования – Xtoolkit

 

Ох, нелегкая это работа...

 

Научиться писать приложения под X Window довольно трудно: для этого необходимо овладеть многими понятия- ми и механизмами. Однако посте крутого подыми откры­вается широкое плато: создание и модификация разнооб­разных приложений происходит с использованием одной и той же технологии. Это свойство характерно именно для систем в рамках объектно-ориентируемой идеологии.

Впрочем, ходить по плато далеко не просто. Для облег­чения этой задачи и появились надстройки Motif (предло­женная Open Software Foundation) и OpenLook (версия Sun Microsystems). Сейчас большая часть программистов, связанных с X Window, работает именно с этими надстрой­ками. И Motif, и OpenLook, сохраняя все преимущества ра­боты в среде X Window, берут на себя массу рутинных про­блем, возникающих при создании приложений.

Основу объектно-ориентированной разработки прило­жений формирует XToolkit. Предполагается, что разработ­чики пользуются не просто этой библиотекой, а надстрой­ками над ней - библиотеками виджетов. Наиболее простая такая библиотека, Aphena Widgets, была создана вместе с XToolkit и доступна так же, как и он сам. Во многом обе на­званные библиотеки ученические, экспериментальные. Тем не менее, в них реализованы основные идеи объектного X-программирования.

Основная часть системы X Motif представляет собой профессиональную библиотеку - замену Aphena Widgets. Система Open Look еще более продвинутая: ее разработчи­ки переписали заново и большую часть XToolkit, сохранив при этом основные принципы и механизмы.

 

Языки профессионального общения

 

Система X Window написана на С и, несмотря на явную "необъектность" этого языка, выдержана в строгом объект­ном стиле.

Программисту, знающему C++, могут показаться забав­ными (раздражающими?) усилия, затраченные сотрудни­ками MIT (Массачусетский Технологический Институт -"родина" X Window) на имитацию производных классов и виртуальных функций. Но следует напомнить, что при за­пуске этого суперпроекта (1984 год) объектно-ориентиро­ванные языки программирования были не только не мод­ными, но весьма неэффективными (первое издание класси­ческой книги Страуструпа о C++ датировано 1986 годом).

Например, во включаемых файлах X Window довольно часто встречаются описатели структур типа:

 

 

struct  DerivedClass   {

struct  BasedGlass  Base;

int make_compiler_happy;

};

 

 

 

Объявлена структура DerivedClass, состоящая из струк­туры BasedClass и не использующейся переменной make_compiler_happy. Вернее, последняя переменная ис­пользуется, но только чтобы не ругался стандартный ком­пилятор с языка С. В свою очередь, не исключено, что стру­ктура BasedClass не порождена таким же образом из еще какой-либо, например, ProBasedClass, а та, в свою очередь... Так что работы компилятору в этих текстах хоть отбавляй, и пожелание "сделать егр рчартливым" актуально.

На языке C++ разумнее было бы использовать конст­рукцию типа:

 

 

class  DerivedClass:   public   BasedClass   {};

 

 

Это историческое досадное обстоятельство имело и положительную сторону: оно послужило одной из причин по­явления идеи ресурсов, до которых мы вскоре доберемся.

(В последнее время появилась информация о новой версии X Window Release 6. Анонсировано, что переписы­вание системы на C++ все же состоялось. Вполне вероятно, что через некоторое время начнется новая страница Х-жиз-ни: новая версия базовых библиотек Х-Window имеет шанс существенно потеснить сферы применения X Motif и Open Look.)

 

Еще одна попытка объяснить понятие "виджет"

 

Автору неизвестно, было ли слово "widget" в англий­ском языке до наступления времени X и что это слово могло означать. Автору не удалось и найти короткое и вразумительное определение этого понятия в литературе или услышать его в личной беседе. Короче, термин "вид­жет" сродни термину "сепульки" у Станислава Лема. На­до стать инопланетянином, чтобы прочувствовать слово "сепульки", и надо программировать объектно-ориенти­рованные системы с оконным интерфейсом, чтобы по­нять всеобъемлющий термин "виджет". При этом знание само по себе не подразумевает способность объяснить смысл термина.

Тем не менее, автор рискует дать свою, быть может, весьма субъективную, трактовку.

Виджет - это, бесспорно, объект. Как правило, он свя­зан с окном в смысле библиотеки XLib. Вообще говоря, верно и обратное: каждое окно при программировании с участием XToolkit связано с некоторым виджетом (од­ним). Встречаются, правда, и исключения. Окна, не свя­занные с виджетами, - это эффект программирования на XLib без XToolkit, своего рода атавизм. Виджеты, не свя­занные с окнами, на самом деле с окнами все-таки связа­ны, но с невидимыми (или несуществующими для Х-сер-вера).

Цель виджетов - контроль за своими окнами, их пра­вильное отображение и, что самое главное, поддержка определенного поведения окна, т.е. стиля реакции эле­ментов окна на события, происходящие в сеансе работы с  X Window. Виджеты служат более или менее автоном­ными кирпичиками, из которых составляется интерфейс почти всех Х-клиентов. Наиболее очевидные примеры: кнопки, полосы прокрутки (Scroll Bars), окна диалога и многие другие. Структура объектов-виджетов практически совпада­ет со структурой их окон, вложенных в друг друга. Есте­ственно, первое существенное деление виджетов - на простые и составные. В отличие от простых, составные виджеты в состоянии управлять своими потомками. В классической схеме объектно-ориентированного про­граммирования эта иерархия так и называется - иерар­хия объектов.

Далее, виджеты делятся по типам: кнопки - это один тип, полосы прокрутки - другой... Но точно ли кнопки -это один тип, а не несколько, очень похожих один на дру­гой, но все же различающихся? Или точно ли при реали­зации виджетов не приходится отлаживать одни и те же механизмы? Экономить усилия помогает иерархия классов. Действительно, вместо того чтобы создавать класс объектов с нуля, разумнее и быстрее взять уже су­ществующий класс объектов, сколько-нибудь похожий на требуемый, и модифицировать его.

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

Так возникает иерархия классов: виджеты могут быть порождены друг из друга путем модификаций и, естест­венно, наращиванием числа внутренних параметров. На ' C++, как известно, такое наращивание совершенно есте­ственно, но на С вызывает ряд проблем.

Главная проблема - как задавать и изменять парамет­ры виджетов? Нет, не умозрительно, а руками, в про­грамме? В файле настройки или еще где-нибудь? Раз­личные параметры виджета разбросаны по нескольким (иногда десяткам) вложенных друг в друга структур. Не помнить же наизусть названия всех этих структур?

Разработчики X Window предложили способ разре- ( шения данной проблемы. Терпеливый читатель, добрав­шийся до этого места, наверное, догадался, что на сцене наконец-то появляются главные герои - ресурсы.

 

 

Ресурсы для виджетов или виджеты для ресурсов?

 

Имена, типы, конвертеры

 

Схема, предложенная разработчиками XToolkit, такова.

1.  Все объекты, классы и типы надо именовать. Каждо­му виджету должно соответствовать две символьных стро­ки: имя класса виджетов и имя объекта-виджета. Каждому параметру виджета должно соответствовать три имени: имя типа параметра, имя класса параметра и имя самого пара­метра. Имена классов и типов обязаны начинаться с про­писных букв, а имена объектов - со строчных.

2.  Именованные параметры виджетов называются ре­сурсами. При регистрации нового класса виджетов на уров­не библиотеки XToolkit должен быть указан список ресур­сов этого класса и список ресурсов каждого объекта данно­го класса. Если виджет является производным от некоторо­го другого виджета (а исключений из этого правила прак­тически не существует), списки ресурсов должны начи­наться со списка ресурсов предка. Про каждый ресурс из обоих списков требуется указать:

- имя типа ресурса;

- имя класса ресурса;

- имя ресурса;

- привязка к месту ресурса в структуре данных виджета (или класса виджетов);

- значение ресурса по умолчанию.

3.   Значения ресурсов контролируются несколькими способами:

-  при регистрации нового класса впджета надо указать значение его ресурсов по умолчанию;

-  при создании нового объекта-виджета его ресурсы первоначально устанавливаются в соответствии с правила­ми умолчания; если в специальных конфигурационных файлах (см. ниже) указаны другие значения для некоторых ресурсов, то устанавливаются именно эти значения;

- при создании виджета, а также при работе с ним, биб­лиотека XToolkit предоставляет возможности явно опра­шивать и изменять значение любого ресурса в процессе вы­полнения приложения.

4. Документация на каждый виджет должна содержать таблицу всех его ресурсов с указанием имен ресурсов, имен их типов, значений по умолчанию и атрибутов изменения значения ресурса. Под последним подразумевается один из нескольких вариантов:

-  (по умолчанию) значение можно и опрашивать, и ме­нять;

- значение можно только опрашивать;

- значение может автоматически измениться при изме­нении другого ресурса;

- значение ресурса определяется при создании виджета и не может измениться в дальнейшем;                  

- значение ресурса категорически запрещается менять в сеансе работы, поскольку последствия непредсказуемы.

5.  Каждый ресурс имеет свой тип. Тип определяет, в скольких байтах оперативной памяти размещается ресурс и как трактовать их содержимое. XToolkit поддерживает око­ло 40 встроенных типов ресурсов. Но Х-программист мо­жет свободно завести новые типы.

Для задания значения ресурсов разработан механизм преобразования типов ресурсов.

Теперь можно сделать попытку дать короткое определе­ние понятия "виджет": это объект, связанный с окном X Window, имеющий строго определенный список именован­ных параметров, называемых ресурсами, и выполняющий, в соответствии со значениями этих параметров, строго оп­ределенные действия, в основном, по поддержке интерфей­са приложения в своем окне. Объекты-виджеты образуют иерархию вложенных друг в друга (и, соответственно, под­чиненных) объектов; классы виджетов образуют иерархию в соответствии с вложенными друг в друга списками ресур­сов и реализацией методов производных виджетов с ис­пользованием методов базовых виджетов.

Определим и XToolkit. Это библиотека, поддерживаю­щая механизмы по работе с виджетами:

- несколько "самых базовых" виджетов;

-  процедуры поддержки функционирования иерархии виджетов;

- процедуры опроса и изменения ресурсов;

-  механизмы управления потоком событий и реакции виджетов на эти события;

- несколько других, более тонких механизмов. Введение понятия ресурсов снимает, как минимум, две

проблемы. Во-первых, это проблема адресации параметров виджетов, затрудненная неадекватностью языка С объект­но-ориентированной идеологии. Во-вторых - унификация работы с ресурсами Х-сервера; действительно, достаточно написать конвертор из типа ресурсов "текстовая строка" в тип ресурсов "шрифт", и работа со шрифтами станет гораз­до удобнее.

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

 

Механизм конфигурирования ресурсов

 

Как уже говорилось, ресурсы разных типов можно кон­вертировать друг в друга. В частности, почти все типы до­пускают конвертирование в вид текстовой строки и обрат­но.

Например, тип "Цвет" естественно задавать либо в виде трех чисел (формат RGB), либо в виде названия этого цве­та. Нетрудно сформировать (и это сделано в X) таблицу цветов: название и числа RGB. Пользователю удобнее ра­ботать с этими названиями, куда более содержательными, чем три числа. Существуют, однако, типы, не поддающиеся осмысленному конвертированию в вид текстовой строки (в частности, это внутренние параметры, связанные с распо­ложением объектов в оперативной памяти. Все нижеследу­ющее на них не распространяется).

-Если ресурсы почти всех типов можно конвертировать из вида текстовой строки, значит, можно завести текстовый файл со значениями каких-либо ресурсов. Файлы эти мож­но менять, не затрагивая исходный код приложения.

При инициализации механизма XToolkit в приложении происходит загрузка двух файлов конфигурации: один файл описывает конфигурацию работы X Window в целом, другой (если он есть) - специальный файл, описывающий конфигурацию именно данного приложения. Имена фай­лов и их расположение в дисковой системе строго оговоре­ны: они либо фиксированы, либо задаются переменными окружения.

Конфигурационные файлы состоят из директив зада­ния значения ресурсов. При инициализации эти директивы подгружаются в небольшую базу данных, поддерживаемую XToolkit. Далее, при создании каждого виджета, наступает фаза переустановки значений ресурсов в соответствии с конфигурационными файлами. На этой фазе XToolkit опрашивает свою базу по каждому ресурсу в отдельности и из всех директив, которые могут относиться к данному ресур­су, выбирает максимально "специальную" директиву, наи­более подробно соответствующую этому ресурсу. Правила выбора этой "самой специальной" директивы достаточно ; сложны, но интуитивно понятны.

Формат каждой директивы довольно прост:

 

путь_к_ресурсу: значение ресурса

 

Постараемся описать, что такое путь к ресурсу. Ресурс -это часть виджета. Виджет, как правило, входит в состав другого виджета. Тот в свою очередь... Но рано или поздно эта цепочка заканчивается головным виджетом приложе­ния. Остается теперь вспомнить, что у каждого ресурса и у каждого виджета есть целых два имени: имя объекта и имя класса. Путь к ресурсу состоит из последовательности этих имен, разделенных точками.

Например, если надо задать ресурс label (класс Label), у виджета а2 (класс А2), находящегося в подчинении видже­та al (класс А1), то директива задания ресурса может вы­глядеть следующими способами:

 

А1.А2.Label: Первый вариант

al.a2. label: Второй вариант                                  

А1. а2.Label: Третий вариант

 

 

 

 

Кроме того, один или несколько элементов и пути мож­но не оговаривать, а заменять их звездочкой ("*"):

 

*.label: Четвертый вариант Al*Label: Пятый вариант

 

Итак, способов задания ресурсов много, но будет по­добрана одна, наиболее специфическая директива. На­пример, при указании в конфигурационном файле всех пяти видов директив, ресурсу присвоится строка "Вто­рой вариант". Действительно, в этом варианте путь к ре­сурсу не содержит пропусков и "пролегает" по именам объектов, более "специальным", нежели имена классов.

Этот механизм очень удобен и для Х-программиста (не надо слишком много внимания уделять мелочам ви­зуализации и можно сосредоточиться на логике про­граммы), и для Х-пользователя, который в любой момент в состоянии изменить внешний вид приложения в соответствии со своими личными представлениями о гармонии цветов, шриф­тов и размеров.

Для того чтобы меха­низм зажил, разработчи­кам Х-приложения надо соответствующим образом оформить документацию либо, на худой конец, пре­доставить файл с какой-нибудь настройкой своей системы. Далее, с помощью разгадывания мнемоник и метода проб и ошибок, ра­зумный пользователь, зна­ющий правила игры, в со­стоянии переконфигури­ровать приложение на свой лад.

 

Резюме

 

 

Все, что описано в этрй статье, не является откро­вением ни для одного про­граммиста, имеющего X-практику.

Однако автор полагает, что знакомство с  Х-Window полезно для само­го широкого круга про­граммистов. Группа моло­дых людей из MIT сумела провести систему по мин­ному полю многооконных и многозадачных интер­фейсов, создав много по­лезных механизмов и со­хранив верность идеям де­мократии. Создавая такую огромную конструкцию, очень просто скатиться  к "авторитаризму". Для этого достаточно сделать несколь­ко простых "управленческих" шагов: объявить сервер головным процессом системы, управляющим своими клиентами (а не только выполняющим их задания); рас­ширить список возможных событий сотней-другой сво­их, системных, никому не ведомых типов; зафиксиро­вать список возможных типов ресурсов.

Система X Window интересна из-за того, что многие объектные идеи существуют в своем "чистом" виде. Хотя не всегда их реализация стройна и проста, она всегда открыта.

Обсуждение механизма ресурсов, как внутри X Window, так и в рамках объектно-ориентированной раз­работки программ в целом, автор хотел бы продолжить в следующей статье.