Построители GUI [Автор неизвестен] (fb2) читать постранично

ПОСТРОИТЕЛИ GUI

Существуют различные средства, предназначенные для построения графических интерфейсов пользователя (GUI). Среди них некоторые используют язык Ада. Вот список некоторых коммерческих построителей GUI для Motif и замеченные недостатки (предоставил Вадим Годунко).

• BX Pro от ICS. BX Pro — совершенно не обеспечивает возможность проведения локализации разрабатываемого интерфейса. Предложенное решение поразило своей новизной: когда интерфейс нарисован и сгенерирован файл ресурсов необходимо загрузить этот самый файл ресурсов и отредактировать там все текстовые надписи.

• X/Designer от IST фактически генерирует код на C и связку с этим кодом на Ada.

• TeleUSE от Aonix — самый навороченный (имеет даже собственный язык написания callback‐ов), но при генерации кода тянет за собой огромную «стандартную библиотеку».

Среди аналогичных средств из «мира Open Source» можно назвать программу Glade, которая позволяет создавать GUI на базе связки GtkAda для переносимого набора тулкита GTK+.

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

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

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

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

Четкая спецификация интерфейса программы может быть использована для автоматизации тестирования логики и реализации интерфейса.

Можно рассмотреть следующий механизм для реализации этого подхода.

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

Спецификация интерфейса может быть выражена в виде спецификации пакета на языке Ада. Для каждого компоненты верхнего уровня (не имеющего родителей) создается отдельных пакетах.

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

Чтобы предоставить интерфейсу методы оповещения о реакции пользователя программа предоставляет свои процедуры используя формальные параметры настраиваемого пакета.

Спецификация интерфейса дает большой простор для его реализации. Описание реализации интерфейса под конкретную платформу хранится в отдельном файле в своем формате. При таком подходе процесс построения приложения может проходить так:

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

• Построение реализации интерфейса для одной из поддерживаемых платформ с использование построителя GUI.

• Генерация исполняемого кода по файлу реализации интерфейса.

• Сборка прикладной части программы с кодом интерфейса.

Идеи построения GUI подобным методом обсуждались в нашей конференции и --">