Xlib

X клиентам не необходимости взаимодействовать с сервером на уровне X протокола. X имеет интерфейс клиента на языке C к протоколу, называемый Xlib. Среди других Xlib предоставляет следующие возможности:

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

• Подпрограммы для отрисовки текста и графики в отрисовываемых элементах.

• Буферизацию запросов к серверу и постановку в очередь событий от сервера.

• Структуры данных представляющие события всех типов и подпрограммы для выбора и чтения событий.

• Подпрограммы для обслуживания цветовых палитр и для использования аппаратно-независимых цветовых пространств.

• Подпрограммы для генерации текстового ввода и вывода в различных локализациях.

• Менеджер ресурсов X (Xrm - X resource manager), базу данных параметров указанных пользователем для приложения.

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

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

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

Xt

Поскольку Xlib предоставляет базовые возможности взаимодействия с X серверо, разработка сложного приложения с использованием только Xlib будет очень сложной задачей. Xlib в сущности предоставляет примитивы для X клиента. Сложные приложения нуждаются в объединеии этих примитивов в конструкции, которые позволяют взаимодействовать с сервером более обобщенным способом.

X включает библиотеку X Toolkit Intrinsics (сокращенно Xt) поддерживающую некоторые из таких высокоуровневых интерфейсов. Три наиболее важных возможности Xt следующие:

• Объекты, известные как виджеты, используемые для содержания данных и представления интерфейса для пользователя.

• Управление геометрией виджетов.

• Диспетчеризации и обработки событий.

Motif

Xt предоставляет фундамент для создания наборов виджет, ответственных за специфические возможности прользовательского интерфейса. Motif использует фундамент Xt для построения как базовых классовтак и различных специализированных подклассов виджетов. Раздел 1.3 содержит описание набора виджетов Motif.

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

Использование Xlib, Xt и Motif

Xt создан как надстройка над Xlib, а Motif - как надстройка над Xt. Единственная цель Xt это предоставление приложению набора высокоуровневых интерфейсов и объектов освобождают программу от взаимодействия с большим количеством простых подпрограмм Xlib. Задача Motif - предоставить приложению устойчивый высокоуровневый интерфейс и, в частности, разнообразный набор виджетов для освобождения программы от необходимости определять свои собственные виджеты для большинства задач.

Тем не менее, Xt не стремится заменить все интерфейсы Xlib, а Motif не ставит своей задачей заменить все интерфейсы Xt. Даже простое Motif приложение должно использовать подпрограммы Xt для инициализации набора компонентов, управления виджетами, создания окон для виджетов, получения и установки ресурсов, добавления процедур обратного вызова и входа в цикл обработки событий.

Многие Motif приложения не нуждаются в использовании подпрограмм Xlib. Тем не менее, Motif не содержит своих собственных графических подпрограмм, средств работы с цветовыми пространствами или поддержки управления методами ввода для приложения. Программы которым необходимы эти возможности должны использовать инструментальные средства других производителей или же напрямую вызывать подпрограммы Xlib.

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

Например, Xlib, Xt и Motif все содержат подпрограммы для установки фокуса клавиатуры в окно или виджет. Xt и Motif оба поддерживают внутренне состояние для отслеживания изменения фокуса. Если Motif приложение использует подпрограммы Xt или Xlib, то это может привести Motif или Xt к внутреннему нессответствию.

По соглашению, имена подпрограмм и структур данных Xlib начинаются с "X"; имена подпрограмм и структур данных Xt начинаются с "Xt"; и, наконец, имена подпрограмм и структур данных Motif начинаются с "Xm".

Эта книга не описывает интерфейсов Xlib и Xt. Разработчик Motif приложений должен знать основные интерфейсы прикладных программ Xt и должен иметь общее представление о Xlib. Для дополнительной информации по Xlib смотрите стандарт X Consortium Xlib - Интерфейс с X на языке C. Для дополнительной информации по Xt смотрите документ X Window System X Toolkit Intrinsics - Интерфейс на языке C.

Классы Xt

Xt опередляет базовые классы для всех виджетов. Core является фундаментальным классом для всех виджетов, которые имеют окна. Этот класс содержит базовые ресурсы геометрии виджетов, цвета фона, трансляций, и чувствительности ввода. Виджетоподобные объекты, которые не имеют окон - называемые в Motif гадгетами - являются подклассами от RectObj. Этот класс содержит реурсы геометрии, но не содержит цветов и трансляций.

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

Shell является базовам классом для всех виджетов-оболочек. Оболочки обертывают другие виджеты чьи окна являюся дочерними от корневого окна. Оболочки отвечают за взаимодействие с менеджером окон. Shell является подклассом Composite. Xt содержит следующие подклассы Shell:

OverrideShell

Окружает виджеты, которые менеджер окон должен игнорировать, такие как меню.

WMShell

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

VendorShell

Подкласс от WMShell реализующий зависимое от набора компонентов поведение.

TransientShell

Подкласс от VendorShell для виджетов типа диалогов которые отображаются ненадолго в интересах других виджетов.

TopLevelShell

Подкласс от VendorShell для виджет верхнего уровня для компонент приложения.

ApplicationShell

Подкласс от TopLevelShell для виджетов верхнего уровня представляющих приложение как единое целое.

Классы Motif

Motif содержит три обширные группы виджетов: примитивы и гадгеты, менеджеры, оболочки.

Файлы заголовков и библиотеки

Xlib, Xt и Motif имеют заголовочные файлы (иниче называемые подключаемыми файлами) которые приложение должно включать в свой код. Однако, заголовочные файлы Motif сами подключают необходимые файлы Xt, которые в свою очередь подключают необходимые файла Xlib. Приложению обычно необходимо подключить только соответствующие файлы Motif.

Все Motif приложения должны подключать файл <Xm/Xm.h>. Этот файл содержит определения, необходимые всем приложениям. Каждый виджет Motif также имеет подключаемый файл. Приложение должно подключить эти заголовочные файлы для всех виджетов, которые оно создает. Дополнительно некоторые группы подпрограмм Motif имеют свои собственные заголовочные файлы. Необходимые подключаемые файлы для каждого виджета и подпрограммы Motif описаны в Справочник программиста Motif.

Вместо использования большого количества заголовочных файлов для конкретных виджетов и подпрограмм приложение может подключить файл <Xm/XmAll.h>. Этот файл объединяет все документированные заголовочные файлы Motif. Подключение <Xm/XmAll.h> может немного замедлить компиляцию; тем не менее его подключение не увеличивает размер результирующего приложения. Другими словами работа редактора связей никак не изменяется в результате подключения <Xm/XmAll.h> вместо подключения индивидуальных заголовочных файлов.

При создании Motif приложения разработчик связать программу с необходимыми библиотеками. Xlib, Xt, набор компонентов Motif и MRM имеют раздельные библиотеки. Приложение которое не использует MRM должно быть связано с библиотеками набора компонентов Motif, Xp, Xext, Xpm, Xt и Xlib. Приложение которое использует MRM должно быть связано с этими библиотеками и дополнительно с библиотекой MRM. Разаработчик также должен связать приложение с дополнительными бибилиотеками, в зависимости от платформы или операционной системы. Проконсультируйтесь у Вашего системного администратора и прочтите документацию производителя для получения дополнительной информации о библиотеках необходимых для Motif приложений.

Метки и разделители

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

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

Разделители Separator или SeparatorGadget разделяют управляющие элементы или их группы. Он обычно выглядит как горизонтальная или вертикальная линия и поддерживает различные стили рисования линии.

Метки и разделители более подробно описаны в главе 5.

Кнопки

Кнопка представляет основной управляющий элемент который позволяет производить действия при его активизации пользователем. Кнопки обычно используются в меню, группах кнопок RadioBoxes и CheckBoxes, диалоговых формах SelectionBoxes и MessageBoxes. Motif имеет следующие классы кнопок:

• Кнопки CascadeButton и CascadeButtonGadget используются внутри меню и когда активизируются обычно отображают выпадающие меню (PulldownMenu).

• Кнопки PushButton и PushButtonGadget могут использоваться как внутри меню так и вне его. Они позволяют выполнять некоторые действия определяемые приложением. Когда кнопка PushButton нажимается или становится готовой к активизации она изменяет свой внешний вид так что пользователь видит что нажал ее. Когда она отпускается, она возвращает внешний вид как будто отжата.

• Кнопки-переключатели ToggleButton и ToggleButtonGadget имеют различные состояния: аналогично переключателям они бывают либо включенными либо выключенными. Они используются в меню или в режимах WorkArea менеджера RowColumn, включая RadioBoxes и CheckBoxes. Они также могут иметь неопределенное состояние.

• Кнопка DrawnButton является пустой кнопкой, окруженной рамкой тени. Она предназначена для использования как кнопка PushButton но с изображением, отрисовываемым приложением.

С большими подробностями кнопки описаны в главе 5.

Полосы прокрутки

Виджет может действовать как окно просмотра в прокручиваемый элемент. Прокручиваемый элемент это плоскость с текстом, графикой, списком элементов или другим содержимым. Окно просмотра это фиксированного размера окно в котором видно часть прокручиваемого элемента.

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

Более детально полосы прокрутки описаны в главе 5.

Списки

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

Подробнее списки обсуждаются в главе 5.

Текст

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

Текст может быть многострочным или ограниченными одной строкой. В однострочном текстовом виджете действия, перемещающие вверх и вниз на одну строку в многострочном виджете, производят переход фокуса на другой виджет, а нажатие osfTab перемещает клавиатурный фокус на другую группу виджетов вместо вставки символа табуляции /textit{Tab}.

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

Дополнительно текстовые виджеты описаны в главах 5 и 10.

Рамки

Рамка (Frame) это простой менеджер который окружает единственного потомка тенью и свободным полем. Рамка также может иметь другого потомка который отображается как название рамки.

Рамки более подробно описываются в главе 8.

Регуляторы

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

Подробнее регуляторы рассмотрены в главе 5.

Окна панелей

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

Дополнительную информацию об окнах пнелей можно найти в главе 8.

Окна прокрутки и главные окна

Окна прокрутки (ScrolledWindow) управляют окном просмотра и полосами прокрутки для реализации окна в виртуальный прокручиваемый элемент. Пользователь может перемещать окно просмотра для отображения различных частей прокручиваемого элемента с использованием полос прокрутки или клавиатурных команд прокрутки.

Окно прокрутки способно автоматически проиводить операции прокрутки. В этом режиме приложение создает виджет, который представляет прокручиваемый элемент, как потомкаокна прокрутки. Окно прокрутки затем создает окно отсечения для выполнения функций окна просмотра, создает и берет на управление полосы прокрутки и изменяет содержимое окна просмотра в ответ на команды прокрутки выдаваемые пользователем.

Окно прокрутки также может позволять приложению выполнять операции прокрутки. В этом режиме приложени само может создать и взять на управление полосы прокрутки и должно изменять содержимое окна просмотра в ответ на действия пользователя.

Списки и текстовые виджеты обычно используются в качестве прокручиваемых элементов. Motif содержит соответствующие процедуры для создания списков и тескстовых виджетов внутри окна прокрутки, о получающиеся прокручиваемые списки (ScrolledList) и прокручиваемые текстовые (ScrolledText) виджеты выполняющие операции прокрутки без участия приложения.

Главное окно (MainWindow) является подклассом окна прокрутки которое предназначено для использвание как главное окно приложения. В дополнение к окну просмотра и полосам прокрутки главное окно содержит необязательные полосу меню (MenuBar), командное окно и окно сообщений.

Более подробно виджеты Окно Прокрутки и Главное окно описываются в главе 8.

Строки-Столбцы

Строки-Столбцы (RowColumn) реализуют как меню так и Рабочие Области (WorkAreas). Меню это виджеты которые позволяют пользователю сделать выбор из действий или состояний. Motif поддерживает четые базовые вида меню:

• Полоса меню (MenuBar) обычно используется в Главном Окне приложения и иногда в других компонентах. Чаще всего она состоит из строки Каскадных Кнопок которые, когда активизируются, вызывают появление Выпадающих Меню.

• Всплывающие меню (PopupMenu) состоит из набора выборов который применим к некоторой компоненте приложения. Меню не видимы пока пользователь не выполнит действия которые вызовут вывод меню. Оно может содержать кнопки которые непосредственно выполняют действия или Каскадные Кнопки для вызова появления Выпадающих Меню.

• Выпадающие меню связываются с Каскадными Кнопками в Полосах Меню, Всплывающих Меню или других Выпадающих Меню. Эти меню также не видны пока пользователь не вызовет их появления активизацией связанной Каскадной Кнопкой. Аналогично Всплывающим Меню, Выпадающие Меню могут содержать кнопки которые выполняют непосредственные действия или Каскадные Кнопки которые вызывают появление других Выпадающих Меню.

• Меню Опций позволяют пользователю делать выброр из одного набора выборов, обычно являющихся уникальными атрибутами или состояниями. Оно состоит из метки, Гадгета Каскадной Кнопки чья метка отображает текущую выбранную опцию, и Выпадающего Меню содержащего кнопки которые представляют набор параметров.

Одно из применений режима Рабочей Области виджета Строки-Столбцы состоит в содержании набора кнопок ToggleButton для образования наборов кнопок RadioBox и CheckBox. Когда пользователь выберет кнопку ToggleButton ее состояние изменится с включено на выключено или с выключено на включено. Другим применением является расположение некоторого набора виджетов в строки, колонки и двухмерные структуры.

RowColumn описан более подробно в главе 6.

BulletinBoard (Доска Объявлений), Form (Форма), MessageBox (Поле Сообщения), SelectionBox (Поле Выбора)

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

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

• SelectionBox (Поле Выбора) является подклассом BulletinBoard который позволяет пользователю сделать выбор из списка вариантов. Он обычно содержит список, редактируемое текстовое поле отображающее выбор и три или четыре кнопки для принятия или отмены выбранного варианта и вызова справочной информации.

• FileSelectionBox (Поле Выбора Файла) является специализированным подклассом SelectionBox для выбора файла из каталога. Он состоит два текстовых поля, одно из которых содержит шаблон поиска файла, другое содержит имя выбранного файла; два списка, один отображающий имена файлов, а другой - имена подкаталогов; и набор кнопок.

• Command (Команда) является специализированным SelectionBox для ввода команд. Его основными составляющими являются текстовое поле для редактирования команд и список представляющий историю введенных команд.

• MessageBox (Поле Сообщений) представляет подкласс BulletinBoard для отображения сообщений для пользователя. Он обычно содержит символ сообщения, текст сообщения и до трех кнопок. Motif предоставляет индивидуальные символы для различных видов сообщений: ошибок, предупреждений, информации, вопросов и оповещении о занятости приложения.

• TemplateDialog является специализированным MessageBox который позволяет приложению создавать собственные диалоги с дополнительными потомками, такими как полосы меню и дополнительными кнопками.

• Form является подклассом BulletinBoard позволяющим производить основанное на ограничениях управление геометрией. Потомки Form имеют ресурсы, представляющие привязку к другим потомкам или самой форме, смещения относительно привязки и относительное положение внутри формы. Form вычисляет положение и размер своих потомков частично основываясь на этих ограничениях. Эта функция расположения потомков делает Form часто применяемым и вне диалогов.

Диалоги описываются более подробно в Главе 7.

DrawingArea (Область Рисования)

DrawingArea является менеджером предназначенным для использования в качестве области, содержащей графические объекты. Приложение должно взаимодействовать с DrawingArea на значительно более низком уровне чем с другими Motif виджетами, но DrawingArea предоставляет приложения более мелкоуровневую информацию о событиях. DrawingArea содержит процедуры обратного вызова для оповещения приложения когда выставляется или изменяет размер и когда он принимает ввод с клавиатуры или от мыши. Приложение обычно должно использовать подпрограммы Xlib для отрисовки в DrawingArea и приложение отвечает за обновление содержимого когда это необходимо. Гибкость DrawingArea делает его часто используемым видетом для реализации как графических так и текстовых возможностей, не предоставляемых другими Motif виджетами.

DrawingArea описывается более подробно в Главе 15.

ComboBox (Поле со Списком)

Виджет ComboBox совмещает возможности виджета TextField и виджета List. Он позволяет пользователю вводить информацию через TextField и также предоставляет список возможных значений через List для завершения ввода в текстовое поле. Приложение предоставляет массив композитных строк которые заполняют этот список и также устанавливет количество видимых элементов списка. Если в списке содержится большее число элементов чем может быть видно (определяется значением ресурса \textbl{XmNvisibleItemCount}), то отображается вертикальная полоса прокрутки позволяющая пользователю прокручивать содержимое списка. Список может отображаться все время, или он может выводиться пользователем посредством нажатия на кнопку вниз при "выпадающем вниз" стиле ComboBox.

Текстовое поле в ComboBox может быть редактируемым или нередактируемым. Если TextField является редактируемым, то пользователь может непосредственно произвести набор в поле для ввода вюбора. Если оно не редактируемо, то печать текста может вызвать алгоритм поиска который позволит сделать выбор из списка используя символы, набранные пользователем. В обоих случаях элемент списка может быть выбран с помощью клавиатуры или мыши. Когда элемент является выбранным, он отображается в реверсных цветах и списке и отображается в текстовом поле ComboBox.

ComboBox более подробно описан в Главе 6.

Spin Boxes (Счетчик)

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

SimpleSpinBox является "готовым к использованию" подклассом от SpinBox. Текстовое поле для SimpleSpinBox создается автоматически.

SpinBox и SimpleSpinBox более подробно описаны в Главе 6.

Container (Контейнер)

Container является менеджером, который принимает потомков только класса XmIconGadget или его подклассов. Он выстраивает этох потомков в различных форматах и просматривать в зависимости от установок их ресурсов, и позволяющий производить выделение и манипулирование потомками.

Более подробно Container описан в Главе 8.

Notebook (Записная книжка)

Notebook является менеджером который отображает только одного потомка в одно время. Каждый потомок имеет назначенный ему номер страницы в Notebook и отображается пользователем посредством нажатия клавиши табуляции или прокрутчиков странжиц в Notebook.

Подробнее Notebook описан в главе 8.

VendorShell (Оболочка Производителя)

VendorShell является классом оболочек предоставляющим Motif-специализированное поведение для оболочек кроме тех, которые окружают меню. Он отвечает за взаимодействие между приложением и MWM. VendorShell является суперклассом для других подклассов. TopLevelShell является Xt подклассом VendorShell который окружает виджеты верхнего уровня в приложении. ApplicationShell это другой Xt подкласс от VendorShell который окружает главный виджет в приложении.

Многие приложения создают только один ApplicationShell. Программа должна создать эту оболочку непосредственно или использовать удобную Xt подпрограмму XtAppInitialize для инициализации приложения и автоматического создания ApplicationShell. (От автора перевода: в версии X Window X11R6.3 введена более обобщенная подпрограмма инициализации приложения XtOpenApplication, а подпрограмма XtAppInitialize считается устаревшей.)

DialogShell (Оболочка диалога)

DialogShell является подклассом VendorShell который окружает диалоги. Поскольку менеджер окон учитывает обобенности диалогов, которые обычно являются временными; они обычно появляются для предоставления пользователю информации или запроса информации от пользователя, а затем они исчезают. DialogShell является подклассом от Xt класс TransientShell, который отслеживает приложение к которому отностися диалог. Пользователь не может свернуть диалог в иконку отдельно от главного окна приложения.

DialogShell разработан для содержания потомка который является подклассом от BulletinBoard. Большинство удобных подпрограмм Motif которые создают диалоги автоматически создают и DialogShell как предка.

MenuShell (Оболочка Меню)

MenuShell является классом оболочек, предназначенным для окружения PopupMenu (Всплывающих меню) и PulldownMenu (Выпадающих Меню). MenuShell является подклассом Xt класса XtOverrideShell. Этот класс позволяет оболочке обходить менеджер окон. Большинство удобных подпрограмм Mofit которые создают PopupMenus и PulldownMenus автоматически создают предка класса MenuShell.

Приложения

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

Виджетом, который представляет приложение обычно является MainWindow. Для большинства приложений необходимые операции должны быть доступны из Полосы Меню, находящейся вверху Главного Окна. Посредством просмотра Полосы Меню пользователь быстро определяет какие основные функции предоставляет приложение. Процедуры обратного вызова активации кнопок в меню которые выпадают из Полосы Меню инициируют выполнение операций в приложении. Руководство по стилю Motif содержит описание необходимых и рекомендуемых компонентах для заполнения Полосы Меню приложения и его Выпадающих Меню.

Главное Окно обычно содержит большую прокручиваемую рабочую область. Однокомпонентное приложение обычно производит большую часть своей работы используя эту область. Другие приложения могут потребовать более одной рабочей области.

ApplicationShell заключает главный виджет приложения. Разработчик должен использовать функцию Xt XtAppCreateShell для непосредственного создания ApplicationShell или дать Xt возможность самостоятельно создать оболочку в процессе вызова XtAppInitialize.

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

Виджеты верхнего уровня

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

Каждый важный компонент приложения может распологаться в виджете верхнего уровня. Каждый виджет верхнего уровня должен быть заключен в TopLevelShell или в ApplicationShell. Одним их подходов является наличие только одного ApplicationShell для приложения, для которого каждый TopLevelShell является всплывающим потомком от ApplicationShell. При этом программа не создает окна для ApplicationShell. Другой подход заключается в том, чтобы назначить один виджет верхнего уровня для приложения, заключенный в ApplicationShell, и сделать остальные TopLevelShell выпадающими потомками ApplicationShell. Выпадающий потомок это единственный чье окно является потомком корневого окна и чья геометрия не управляется его родительским виджетом.

Множественные виджеты верхнего уровня описаны более подробно в Главе 3.

Диалоги

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

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

Более подробно диалоги описываются в Главе 7.

Начальная база данных ресурсов

Подпрограмма XtDisplayInitialize строит начальную базу данных ресурсов для приложения. Приложению редко требуется производить непосредственный вызов этой подпрограммы; она вызывается из XtOpenDisplay, которая вызывается из XtAppInitialize.

XtDisplayInitialize строит отдельную базу данных ресурсов для каждого дисплейного соединения. Начальная база данных ресурсов комбинирует значения ресурсов полученные из командной строки, дисплея, файла умолчаний класса приложения и файлов умолчаний пользователя, которые могут быть специализированы соответственно для приложения или для компьютера на котором приложение запущено. Значения по умолчанию для класса приложения и пользовательские значения по умолчанию для каждого приложения могут быть еще более специализированны в соответствии с используемым естественным языком и, возможно, в соответствии с ресурсом предпочтений общего назначения. Ресурсы в начальной базе данных могут быть заданы для конкретного виджета или класса виджетов, а также и для приложения в целом. Когда приложение создает виджеты значения, указанные в базе данных, чаще всего являются исходными для начальных значений ресурсов виджета.

В оставшейся части этого раздела описавается последовательность в которой XtDisplayInitialize загружает каждый компонент базы данных и как она определяет расположение этого компонента.

Пути поиска файлов

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

• %N заменяется на имя класса приложения, определенное аргументом application_class при вызове XtAppInitialize, XtOpenDisplay или XtDisplayInitialize.

• %C заменяется на значение ресурса предпочтений.

• %L заменяется на спецификацию используемого для дисплея естественного языка. Она может быть взята из ресурса xnlLanguage, локализации приложения или соответствующей процедуры обратного вызова приложения. Смотрите главу 11 для получения более подробной информации. Формат спецификации языка зависит от реализации, она может содержать компоненты языка, территории и набора знаков.

• %l заменяется на компоненту языка из спецификации языка.

• %t заменяется на компоненту территории из спецификации языка.

• %c заменяется на компоненту набора символов из спецификации языка.

• %% заменяется на %.

Если спецификация языка не задана или одна из компонент спецификации отсутствует, соответствующий элемент заменяется на NULL.

Пути состоят из последовательности елементов, разделенных двоеточиями. Каждый элемент рассматривается как имя файла. Элементы просматриваются слева на право пока один из них не укажет на существующий файл. Перед просмотром производятся подстановки.

Xt использует соглашение X/Open по слиянию нескольких подряд идущих символов '/' в единственный символ '/'.

Компоненты начальной базы данных

Функция XtDisplayInitialize загружает базу данных ресурсов слиянием ресурсов из следующих источников в порядке превосходства (т.е. каждый компонент имеет превосходство перед последующими компонентами):

• Командная строка приложения.

• Специфичный для компьютера файл ресурсов окружения пользователя на локальном компьютере.

• Специфичные для экрана ресурсы для экрана по умолчания на дисплее.

• Свойство ресурсов сервера или ресурсный файл предпочтений пользователя на локальном компьютере.

• Специфичный для приложения ресурсный файл пользователя на локальном компьютере.

• Специфичный для класса приложения ресурсный файл на локальном компьютере.

Спецификации в командной строке

XtDisplayInitialize вызывает функцию XrmParseCommand менеджера ресурсов X для извлечения значений ресурсов из командной строки посредством которой пользователь запустил приложение. Аргументы командной строки и их количество передаются посредством параметров argv и argc в подрограммы XtAppInitialize, XtOpenDisplay или XtDisplayInitialize. Xt поддерживает стандартный набор аргументов командной строки, таких как -background и -geometry, для задания значений ресурсам. Приложение может указать дополнительные аргументы в параметрах подпрограмм XtAppInitialize, XtOpenDisplay или XtDisplayInitialize. Пользователь может применять аргумент -xrm для установки любого ресурса в базе данных.

Специфичные для компьютера ресурсы пользователя

Для загрузки специфичных для компьютера ресурсов окружения пользователя XtDisplayInitialize использует имя файла определенное переменной окружения XENVIRONMENT. Если XENVIRONMENT не определена, то XtDisplayInitialize ищет файл $HOME/.Xdefaults-host, где host имя компьютера, на котором запущено приложение (т.е. имя компьютера клиента, а не сервера).

Специфичные для экрана ресурсы

Для загрузки специфичных для экрана ресурсов XtDisplayInitialize просматривает свойство SCREEN_RESOURCES у корневого окна на экране по умолчанию дисплея. Свойство SCREEN_RESOURCES обычно является результатом выполнения команды xrdb когда некоторые ресурсы не задаются для всех экранов.

Когда Xt требуется получить ресурсы для экрана отличного от используемого по умолчанию на дисплее, например, если приложение создает виджет на другом экране, он использует свойство SCREEN_RESOURCES этого экрана вместо свойства SCREEN_RESOURCES экрана по умолчанию.

Ресурсы сервера или ресурсы предпочтений пользователя

Для загрузки свойства ресурсов сервера или файла ресурсов предпочтений пользователя XtDisplayInitialize просматривает свойство RESOURCE_MANAGER у корневого окна экрана 0 на дисплее. Свойство RESOURCE_MANAGER обычно является результатом выполнения команды xrdb когда некоторые ресурсы задаются для всех экранов. Если это свойство не существует, то XtDisplayInitialize просматривает файл $HOME/.Xdefaults.

Пользовательский файл приложения

Для загрузки пользовательского файла ресурсов приложения XtDisplayInitialize выполняет следующие шаги:

1. Использует XUSERFILESEARCHPATH для поиска файла, выполняя необходимые подстановки.

2. Если это не дает результата или же XUSERFILESEARCHPATH не определена и определена XAPPLRESDIR использует зависимый от реализации путь, содержащий по меньшей мере семь элементов, в следующем порядке и с следующими префиксами директорий и подстановками:

   • $XAPPLRESDIR с %C, %N, %L или с %C, %N, %l, %t, %c

   • $XAPPLRESDIR с %C, %N, %l

   • $XAPPLRESDIR с %C, %N

   • $XAPPLRESDIR с %N, %L или с %N, %l, %t, %c

   • $XAPPLRESDIR с %N, %l

   • $XAPPLRESDIR с %N

   • $HOME с %N

   где $XAPPLRESDIR - значение переменной окружения XAPPLRESDIR, а $HOME - домашний каталог пользователя.

3. Если XAPPLRESDIR не определена используется определяемые реализацией пути поиска, содержащие по крайней мере шесть элементов в следующей последовательности и со следующими каталогами и подстановками:

   • $HOME с %C, %N, %L или с %C, %N, %l, %t, %c

   • $HOME с %C, %N, %l

   • $HOME с %C, %N

   • $HOME с %N, %L или с %N, %l, %t, %c

   • $HOME с %N, %l

   • $HOME с %N

Ресурсный файл класса приложения

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

• %C, %N, %S, %T, %L или %C, %N, %S, %T, %l, %t, %c

• %C, %N, %S, %T, %l

• %C, %N, %S, %T

• %N, %S, %T, %L или %N, %S, %T, %l, %t, %c

• %N, %S, %T, %l

• %N, %S, %T

где подстановка для %S обычно NULL, а подстановка для %T обычно app-defaults.

Если специфичный для класса приложения файл ресурсов не найдет, то XtDisplayInitialize просматривает ресурсы отката, которые могут быть заданы при вызове XtAppInitialize или XtAppSetFallbackResources.

Установка ресурсов в процессе инициализации виджета

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

• Значения по умолчанию определенные классом виджета либо его суперклассом

• Знаяения ресурсов из начальной базы данных ресурсов.

• Значения ресурсов указанные приложением при вызове подпрограммы создания виджета.

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

Документация на каждый класс виджетов в Motif. Справочник программиста приводит список типов данных и значений по умолчанию для каждого ресурса. Для ресурсов чьи значения по умолчанию вычисляются динамически документация описывает как определяются эти значения.

Аргументы для задания значений ресурсов

Для указания начальных значений ресурсов при вызове подпрограммы создания виджета приложение предоставляет два аргумента: список элементов, представляющих значения ресурсов и целое число указывающее количество элементов в списке. Каждый элемент списка представляет структуру типа Arg. Эта структура состоит из двух полей: строки, определяющей имя ресурса и значения определяющего необходимое значение ресурса. Указываемое значение имеет тип XtArgVal. Этот тип данных имеет размер, достаточные для сохранения значений длинного целого типа или одного из различных типов указателей на данные. Если значение ресурса является типом меньшим чем может быть задано в XtArgVal, то заносится непосредственное значение ресурса, а иначе заносится указатель на необходимое значение. Для большинства ресурсов приложение определяет целочисленные значения (включая тикие типы как Position и Dimension) прямо в поле, определяющем значение ресурса, а иначе в это поле приложение заносит указатель на занчение.

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

... Widget text; Arg args[10]; Cardinal n; n = 0; XtSetArg(args[n], XmNrows, 10); n++; XtSetArg(args[n], XmNcolumns, 80); n++; text = XmCreateText("text", parent, args, n);

Вместо использования списка Arg, подпрограммы с переменным списком аргументов позволяют определять значения ресурсов как переменное число пар из имени ресурса и его значения. Значения ресурса в каждой паре имеет тип XtSetArg с тем же смыслом что и значение в структуре Arg. Приложение может указать две специальные строки вместо имени ресурса. Если указывается имя \textbl{XtVaNestedList}, то следующий аргумент интерпретируется как вложенный список пар имя-значение. Если же указано имя \textbl{XtVaTypedArg}, то последующие четыре аргумента предоставляют значение ресурса и указывает на необходимость произвести преобразование одного типа данных в другой, как это описано в следующем разделе.

Установка значений ресурсов

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

... Arg args[10]; Cardinal n; n = 0; XtSetArg(args[n], XmNrows, 10); n++; XtSetArg(args[n], XmNcolumns, 80); n++; XtSetValues(text, args, n);

Каждый класс виджетов имеет собственную процедуру установки значений set_values. После установки значений из указанного списка аргументов, XtSetValues вызывает процедуру set_values для каждого класса в иерархии классов виджета в очередности от суперкласса к подклассу. Процедура set_values может установить новые значения ресурсов отличных от указанных аргументами XtSetValues. Это обычно происходит когда значение одного ресурса зависит от другого. Установка новых значений для ресурсов которые влияют на геометрию виджета может также заставить Motif перерасчитать расположение виджета. В некоторых случаях процедура set_values принуждает ресурс иметь определенное значение не обращая внимание на то, что приложение желает указать другое значение.

Извлечение значений ресурсов

Для извлечения значений ресурсов приложение может использовать XtGetValues или XtVaGetValues. Их аргументы аналогичны аргументам XtSetValues за исключением того, что вместо значения каждого ресурса указывается адрес по которому Motif сохраняет запрашиваемые значения:

... Arg args[10]; Cardinal n; short nrows, ncolumns; n = 0; XtSetArg(args[n], XmNrows, &nrows); n++; XtSetArg(args[n], XmNcolumns, &ncolumns); n++; XtGetValues(text, args, n);

Типы данных значений ресурсов

Документация на каждый класс виджетов в Motif. Справочник программиста перечисляет типы двнных, используемые при установке и извлечении значений ресурсов. Пользователь или приложение не всегда имеют возможность предоставить данные в необходимого типа. Motif содержит подпрограммы,называемые конверторами, которые производят преобразование значений ресурсов из одного типа в другой. например, когда значение для базы данных ресурсов извлекается из файла или командной строки, Motif обрабатывает значение как строку. Motif и Xt содержат подпрограммы для преобразования строк в часто используемые типы ресурсов, включая Boolean, Dimension, Position, Pixel и XmFontList.

Когда используются стандартные подпрограммы создания виджетов, XtSetValues и XtGetValues, приложение должно предоставлять значения ресурсов или адреса на значения тех типов, которые ожидает виджет. Но когда используется версии этих процедур с переменными аргументами, приложение может предоставить значения любого типа для которого имеются подпрограммы преобразования из этого типа в значение ожидаемого типа. Для проведения преобразования типа приложение должно указать \textbl{XtVaTypedArg} вместо имени ресурса в списке аргументов. Вмесо значения ресурса приложение указывает четыре аргумента:

• Имя ресурса

• Строку представляющую тип указываемого значения

• Собственно значение (типа XtArgVal)

• Целое число представляющее количество байт в значении

Например, следующий вызов производит преобразование предоставленной строки в композитную строку которую Motif ожидает в качестве метки для PushButton:

... char *label = "Button"; XtVaSetValues(button, XtVaTypedArg, XmNlabelString, XmRString, label, strlen(label) + 1, NULL);

Не забывайте, что установка значений ресурсов с использованием \textbl{XtVaTypedArg} для некоторых ресурсов гаджетов, текстовых полей и VendorShell работает не корректно.

Значения ресурсов и управление памятью

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

... char *label = "Button"; XmString label_cs; label_cs = XmStringCreateLocalized(label); XtVaSetValues(button, XmNlabelString, label_cs, NULL); XmStringFree(label_cs);

Для ресурсов чьи значения не являются непосредственно данными, XtGetValues иногда делает копию значений, а иногда не делает. Например, Motif всегда делает копию композитной строки извлекаемой посредством XtGetValues, но он не делает копии списка композитных строк (тип данных XmStringTable). приложение должно освободить композитную строку, полученную посредством XtGetValues, но в общем не должно освобождать значения других типов за исключением конкретных ресурсов для которых Motif. Справочник программиста не говорит о том, что приложение должно освободить это значение.

Стандартными подпрограммами, которые приложение должно использовать для выделения памяти, являются XtMalloc и XtNew. Стандартной подпрограммой освобождения памяти является XtFree. Некоторые типы данных Motif имеют собственные подпрограммы управления памятью, которые приложение должно использовать вместо более общих подпрограмм Xt. Например, используйте XmStringFree для освобождения памяти, занимаемой композитной строкой. Таблица 2-3 содержит список подпрограмм освобождения памяти в Motif.

Взятие виджетов на управление

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

Приложение указывает виджету взять на управление геометрию дочерних виджетов посредством вызова XtManageChild или XtManageChildren. Если родительский виджет реализован, то XtManageChild вызывает процедуру change_managed родительского виджета. Эта процедура может изменить размер или положение любого потомка родительского виджета. После вызова процедуры change_managed родительского виджета XtManageChild проводит реализацию потомка и, если ресурс \textbl{XmNmappedWhenManaged} потомка установлен в True, то и отображает его.

Если родительский виджет не реализован, то XtManageChild отмечает, что потомок взят на управление. Xt откладывает вызов процедуры change_managed родительского виджета пока родительский виджет не будет реализован.

Когда берется на управление более одного потомка реализованного родительского виджета приложению более выгодно вызвать XtManageChildren вместо отдельного вызова XtManageChild для каждого отдаваемого на управление виджета. Расположение виджетов может потребовать значительных расчетов, а XtManageChild вызывает процедуру change_managed каждый раз когда вызывается. XtManageChildren вызывает процедуру change_managed только один раз для всех потомков взятых на управление.

Приложение указывает виджету не производить управление геометрией дочерних виджетов посредством вызова XtUnmanageChild или XtUnmanageChildren. С помощью взятия на управление и снятия с управления виджетов приложение может альтернативно отображать более одного набора потомков без применения процедур создания и уничтожения виджетов каждый раз когда изменяется конфигурация приложения. Дополнительно, взятие на управление диалогов и всплывающих меню заставляет виджет появиться на экране, а снятие с управление заставляет исчезнуть с экрана.

Для создания виджета и взятия его на управление в одном вызове приложение может использовать XtCreateManagedWidget или XtVaCreateManagedWidget. Подпрограммы Motif создающие виджеты определенного класса всегда возвращают не взятые на управление виджеты. Когда используются эти подпрограммы приложение должно самостоятельно отдать на управление виджеты используя XtManageChild или XtManageChildren.

Реализация виджетов

Приложение использует XtRealizeWidget для реализации виджета. Эта подпрограмма делает следующее:

• В пост-порядке обходит дерево виджетов, чиьм корнем является виджет и вызывает процедуру change_managed класса для каждого виджета в дереве имеющего взятые на управление потомки.

• Рекурсивно обходит дерево корнем является виджет и вызывает процедуру realize класса для каждого виджета в дереве который взят на управление. Процедура realize создает окна виджетов.

• Отображает вятые на управление потомки виджета у которых \textbl{XmNmappedWhenManaged} установлен в True. Если виджет является виджетом верхнего уровня и ресурс \textbl{XmNmappedWhenManaged} установлен в True, то XtRealizeWidget отображает его.

Имейте в виду следующие:

• Согласование геометрии производится снизу вверх, тогда как создание окон производится сверху вниз.

• После того, как виджет реализован все его взятые на управление потомки реализованы и, по умолчанию, отображены.

• Если в дереве нет реализованных виджетов, то все согласование геометрии между родителями и их взятыми на управление потомками будет проведено перед реализацией любого виджета.

Когда дерево виджетов делается видимым первый раз приложение должно обычно взять на управление все виджеты, а затем реализовать только виджет верхнего уровня. Это приводит к тому, что все начальные размеры и положения потомков и общий размер окна верхнего уровня будет определены пока не существует никаких окон, что уменьшит взаимодействие с X сервером. Это также позволяет приложению реализовать все виджеты одним вызовом XtRealizeWidget.

Отображение виджетов

Большинство приложение не производят непосредственного отображения и снятия с отображения окон виджетов. Отображение обычно имеет место как часть процесс взятия на управление или реализации виджетов. Но имеется возможность предохранить Xt от отображения окон в это время установкой ресурса \textbl{XmNmannedWhenManaged} в False. В этом случае приложение должно непосредственно использовать XtMapWidget для отображения виджета. Приложение может использовать XtUnmapWidget для отмены отображения виджета.

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

Множественные экраны, дисплеи и приложения.

Приложение может быть запущено более чем на одном экране. В этом случае оно должно использовать XOpenDisplay для установления соединения с каждым дисплем и должно затем выполнить XtDisplayInitlaize отдельно для каждого соединения. Ему необходимо создать собственный контекст приложения для каждого дисплея.

XtDisplayInitialize изменяет аргументы argv и argv. Если приложению необходимо вызвать XtDisplayInitialize более чем один раз оно должно сохранить эти аргументы перед первым вызовом и использовать копию сохраненных аргументов для каждого вызова.

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

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

Одним из подходов к использованию нескольких экранов является создание единственной нереализованной оболочки ApplicationShell для дисплея. Приложение затем создает одну оболочку TopLevelShell для каждого экрана как всплывающего потомка от ApplicationShell. Поскольку оболочка способна нормально содержать только один управляемый виджет, она может иметь более чем одного всплывающего потомка. Приложение использует XtAppCreateShell для создания оболочки ApplicationShell и XtCreatePopupShell для создания каждой оболочки TopLevelShell. Если не указывать экран для ApplicationShell, то XtAppCreateShell установит в ресурсе \textbl{XmNscreen} этого виджета экран по умолчанию на дисплее. В списке параметров передаваемом в XtCreatPopupShell приложение должно указать соответствующее значение для ресурса \textbl{XmNscreen} для каждой оболочки TopLevelShell чтобы эта оболочка создается на необходимом экране.

Приложение не должно брать на управление оболочки TopLevelShell. Для реализации и отображения этих оболочек приложение должно использовать XtPopup с аргументом grab_kind установленным в \textbl{XtGrabNone}.

int main(int argc, char **argv) { Widget app_shell, top_shell; XtAppContext app; Display *display; char name[20]; Arg args[5]; Cardinal n; int i; app_shell = XtAppInitialize(&app, "Example", (XrmOptionDescList) NULL, 0, &argc, argv, (String *) NULL, (ARGList) NULL, 0); display = XtDisplay(app_shell); for (I = 0; i < ScreenCount(display); i++) { sprintf(name, "top_shell_%d", i); n = 0; XtSetArg(args[n], XmNscreen, ScreenOfDisplay(display, i)); n++; top_shell = XtCreatePopupShell(name, topLevelShellWidgetClass, app_shell, args, n); /* создание и взятие на управление потомков оболочки */ ... /* реализация и отображение оболочки */ XtPopup(top_shell, XtGrabNone); } ... }

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

Почему многонитевость?

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

Цикл обработки ввода

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

while(TRUE) { XEvent event; XtAppNextEvent(app, &event); XtDispatchEvent(&event); }

app ссылается на контекст Motif приложения. XtAppNextEvent удаляет и возвращает событие из вершины очереди событий X. Если очередь бобытий X пуста, то XtAppNextEvent ожидает поступления события X, между тем просматривая альтернативные источники ввода и значения таймаутов и вызывая все процедуры обратного вызова активированные ими. После возврата из XtAppNextEvent XtDispatchEvent диспетчеризирует событие X в соответствующее место. Диспетчеризация событий X обычно инициирует вызов некоторых обработчиков событий, процедур действий, процедур обратного вызова ввода и таймеров, совместно называемых "процедурами обратного вызова".

Обычно каждое Motif приложение выполняет свою работу в процедурах обратного вызова. Если работа, выполняемая в процедуре обратного вызова требует длительного времени (и невидима), обработка следующего события в очереди событий X может быть заметно задержана, являясь причиной ухудшения отзывчивости приложения. Многонитевость может помочь преодолеть задержки в процессе обработки событий X и таким образом облегчить проблемму плохой отзывчивости (или интерактивности).

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

Интерфейс Xt для многонитевости

Motif очень тесно связан с X Toolkit. Интерфейсы X11R6 для многонитевых приложений требуются только если многонитевое приложение вызывает интерфейсы Motif/Xt из нескольких нитей. Вполне возможно написать многопоточное Motif приложение в котором интерфейсы Motif/Xt вызываются только из одной нити. В таких приложениях этот интерфейс может не потребоваться. В дополнение к этому интерфейсу X11R6 определяет функции и типы двнных, используемые в многонитевой программе, в файле X11/Xthreads.h. Поскольку нитевый интерфейс зависит от операционной системы, подключение этого файла вместо специфичного для системы файла улучшает переносимость.

Инициализация Xt для использования в нескольких нитях

Motif приложение которое создает несколько нитей должно произвести вызов XtToolkitThreadInitialize, которая инициализирует Xt для использования в нескольких нитях. XtToolkitThreadInitialize возвращает True если данный Xt поддерживает многопоточность, а иначе возвращает False.

XtToolkitThreadInitialize может быть вызван перед или после XtToolkitInitialize и может вызываться более чем один раз. Тем не менее, он не может быть вызван параллельно из нескольких нитей. Приложение должно вызвать XtToolkitThreadInitialize перед вызовом XtAppInitialize, XtSetLanguageProc, XtOpenApplication или XtCreateApplicationContext.

Использование XtAppLock и XtAppUnlock

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

Для блокировки и разблокировки контекста приложения, всех виджетов и дисплейного соединения приложение должно использовать XtAppLock и XtAppUnlock.

Все функции Motif и Xt, которые принимают контекст приложения, виджет или дисплейное соединение как параметр, непосредственно блокируют связанный с ними контекст приложения на протяжении выполнения функции. Таким образом, за вычетом нескольких исключений, приложению нет необходимости вызывать XtAppLock или XtAppUnlock. Первым исключением является ситуация в которой приложению необходимо атомарно выполнить некоторую последовательность вызовов функций Xt. В этой ситуации приложение должно заключить последовательность вызовов Xt в соответствующую пару из XtAppLock и XtAppUnlock. Например, если приложению хочет атомарно проверить и обнивить высоту виджета, оно должно сделать это следующим образом:

XtAppContext app; Dimension ht = 0; Widget w; ... XtAppLock(app); XtVaGetValues(w, XtNheight, &ht, NULL); if((int)ht < 10) { ht += 10; XtVaSetValues(w, XtNheight, ht, NULL); } XtAppUnlock(app);

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

• \textbl{XmNchildren}: возвращает указатель на соответствующее поле Composite.

• \textbl{XmNselectedItems}: возвращает указатель на соответствующее поле List.

• \textbl{XmNsource}: возвращает указатель на соответствующее поле Text.

В этих случаях приложение также должно окружать вызов XtGetValues вызовом XtAppLock и XtAppUnlock, чтобы другая нить выполняющаяся на том же экземпляре виджета не смогла изменить значение ресурса. Приложению также необходимо сделать копию извлеченного ресурса.

Для предоставления полностью эксклюзивного доступа к глобальным структурам приложение должно использовать XtProcessLock и XtProcessUnlock.

Как XtAppLock так и XtProcessLock могут быть вызваны рекурсивно. Для разблокирования верхнего уровня XtAppUnlock и XtProcessUnlock должны быть вызваны такое же количество раз как и XtAppLock и XtProcessUnlock соответственно. Для одновременной блокировки контекста приложения и глобальных данных Xt сначала вызывается XtAppLock, а затем XtProcessLock. Для разблокировки сначала вызывается XtProcessUnlock, а затем XtAppUnlock. Порядок вызова очень важен для предотвращения взаимоблокировок.

Новый XtAppMainLoop

Как мы мжем видеть подпрограмма XtAppMainLoop в X11R5 является бесконечным циклом который вызывает XtAppNextEvent, а затем XtDispatchEvent. В многопоточно-безопасном Xt бесконечный цикл в XtAppMainLoop должет предохранять нить обработки ввода от выхода из XtAppMainLoop без одновременного выхода из самой нити. Эта ситуация может привести к следующим проблеммам:

• Потерям памяти.

• "Повисшим" нитям.

• Усложнению синхронизации между нитью обработки ввода и другими нитями.

Для решения этих проблемм Xt версии X11R6 преобразовал XtAppMainLoop. Он стал условным циклом, который вызывает XtAppNextEvent, а затем XtDispatchEvent, но теперь после каждого цикла обработки производит проверку не завершило-ли приложение работу с помощью нового флага выхода в контексте приложения. Если флаг выхода установлен в True, то XtAppMainLoop выходит из цикла обработки ввода. Следующий пример показывает реализацию новой XtAppMainLoop:

XtAppContext app; do { XEvent event; XtAppNextEvent(app, &event); XtDispatchEvent(&event); } while(XtAppGetExitFlag(app) == FALSE);

Флаг выхода в контексте приложения может быть установлен в True посредством вызова XtAppSetExitFlag. Значение флага выхода может быть получено посредством XtAppGetExitFlag. Новая XtAppMainLoop предоставляет эффективный способ уничтожения контекста приложения без необходимости выхода из нити обработки ввода.

Уничтожение контекста приложения

В многонитевых Motif приложениях рекомендуется следующий способ уничтожения контекста приложения: после того как нить обработки ввода выходит из XtAppMainLoop и после того как она определяет, что никакая другая нить не ссылается на соответствующий контекст приложения, она вызывает XtDestroyApplicationContext. Используйте XtAppGetExitFlag для синхронизации между нитью обработки ввода и другити нитями. Вызывайте XtAppSetExitFlag в процедуре обратного вызова, ответственной за выход из приложения. Это заставляет соответствующий XtAppMainLoop вернуть управление, но не завершает нить обработки ввода.

Обработка событий в нескольких нитях

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

Например, предположим, что нить A, являющаяся нитью обработки ввода, блокированна для ввода в XtAppMainLoop, т.е. она находится в стеке блокированных нитей контекста приложения. Предположим также, что одна из других нитей, нить B, обнаружила некоторую ошибочную ситуацию и приняла решение отобразить окно сообщения и временно забрать обработку ввода у нити A. Т.к. блокированные нити помещаются в стек, это позволяет нити B достаточно просто перехватить у нити A обработку ввода на себя. Способ, которым нить B делает это заключается в выполнении некторого подобия цикла обработки ввода внутри соответствующей пары XtAppLock и XtAppUnlock как показано ниже:

/* этот код выполняется нитью, отличной от нити обработки ввода */ XtAppContext app; Widget error_dialog; XEvent event; XtAppLock(app); /* Блокировка контекста приложения */ XtPopup(error_dialog, XtGrabExclusive); /* отображение диалога ошибки */ do { /* собственная обработка ввода */ XtAppNextEvent(app, &:event); if(/* некторое условие вызванное событием */) XtDispatchEvent(&event); } while (/* некоторое условие */); XtAppUnlock(app);

Поскольку нить B вошла в XtAppNextEvent после того, как это сделала нить A, то нить B будет помещена в стек сверху нити A. Впоследствии, когда произойдет ввод, нить B будет извлечена из стека и произведет обработку ввода.