<p><strong>ЧАСТЬ III</strong></p><p><strong>Создание графического интерфейса пользователя и апплетов</strong></p>
Глава 8.Принципы построения графического интерфейса
Глава 9.Графические примитивы
Глава 10.Основные компоненты AWT
Глава 11.Оформление ГИП компонентами Swing
Глава 12.Текстовые компоненты
Глава 13.Таблицы
Глава 14.Размещение компонентов и контейнеры Swing
Глава 15.Обработка событий
Глава 16.Оформление рамок
Глава 17.Изменение внешнего вида компонента
Глава 18.Апплеты
Глава 19.Прочие свойства Swing
Глава 20.Изображения и звук

ГЛАВА 8

<p><strong>Принципы построения графического интерфейса</strong></p>

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

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

За десятилетия развития вычислительной техники создано много различных графических систем: MS Windows, X Window System, Macintosh. В каждой из них свои правила построения окон и их компонентов: меню, полей ввода, кнопок, списков, полос прокрутки. Эти правила сложны и запутаны. Графические API, предназначенные для создания пользовательского интерфейса, содержат сотни функций.

Для облегчения создания окон и их компонентов написаны библиотеки функций и классов: MFC, Motif, OpenLook, Qt, Tk, Xview, OpenWindows, OpenGL, GTK+ и множество других. Каждый класс такой библиотеки описывает сразу целый графический компонент, управляемый методами этого и других классов.

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

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

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

Такие интерфейсы были названы peer-интерфейсами.

Библиотека классов Java, основанных на peer-интерфейсах, получила название AWT (Abstract Window Toolkit). Для вывода на экран объекта, созданного в приложении Java и основанного на peer-интерфейсе, создается парный ему (peer-to-peer) объект графической подсистемы операционной системы, который и отображается на экране. Поэтому графические объекты AWT в каждой графической среде имеют вид, характерный для этой среды: в MS Windows, Motif, OpenLook, OpenWindows, — везде окна, созданные в AWT, выглядят как "родные" окна этой графической среды.

Пара объектов, реализующих один peer-интерфейс, тесно взаимодействуют во время работы приложения. Изменение объекта в приложении Java немедленно влечет изменение объекта графической оболочки и меняет его вид на экране.

Именно из-за такой реализации peer-интерфейсов и других "родных" (native) методов, написанных главным образом на языке С++, приходится для каждой платформы выпускать свой вариант JDK.

В версии JDK 1.1 библиотека AWT была переработана. В нее добавлена возможность создания компонентов, полностью написанных на Java и не зависящих от peer-интерфейсов. Такие компоненты стали называть "легкими" (lightweight), в отличие от компонентов, реализованных через peer-интерфейсы, названных "тяжелыми" (heavy).

Перейти на страницу:

Все книги серии В подлиннике

Похожие книги