Составители:
Рубрика:
66
Существуют высокоуровневые абстракции над D-Bus для фреймворков Qt, Java, GLib, C#, Python и
библиотека для C++.
D-Bus предоставляет системе несколько шин. Системная шина создаётся при старте демона D-Bus
и с ее помощью происходит взаимодействие различных демонов. Сессионная шина создается для
пользователя, авторизировавшегося в системе. Для каждой такой шины запускается отдельная копия
демона, посредством неё будут общаться приложения, с которыми работает пользователь.
Каждое сообщение D-Bus, передаваемое по шине, имеет своего отправителя и своего получателя, их
адреса называются путями объектов, поскольку D-Bus предполагает, что каждое приложение состоит
из набора объектов, а сообщения пересылаются не между приложениями, а между объектами этих
самых приложений.
D-Bus также предусматривает концепцию сервисов. Сервис — уникальное местоположение
приложения на шине. При запуске приложение регистрирует один или несколько сервисов, которыми
оно будет владеть до тех пор, пока самостоятельно не освободит их. До этого момента никакое другое
приложение, претендующее на тот же сервис, занять его не сможет.
Сервисы делают доступной ещё одну функцию — запуск необходимых приложений в случае
поступления сообщений для них. Для этого должна быть включена автоактивация, а в конфигурации
D-Bus за этим сервисом должно быть закреплено одно приложение. Тогда D-Bus сможет его
запустить при появлении сообщения.
После подключения к шине приложение должно указать, какие сообщения оно желает получать,
путём добавления масок совпадений (matchers). Маски представляют собой наборы правил для
сообщений, которые будут доставляться приложению, фильтрация может основываться на
интерфейсах, путях объектов и методах. Таким образом, приложения будут получать только то, что
им необходимо; проблемы доставки в этом случае берет на себя D-Bus.
Сообщения в D-Bus бывают четырёх видов: вызовы методов, результаты вызовов методов,
сигналы и ошибки. Первые предназначены для выполнения методов над объектами, подключенными
к D-Bus; посылая такое сообщение, вы выдаете задание объекту, а он после обработки обязан
возвратить вам либо результат вызова, либо ошибку через сообщения соответствующих типов.
Сигнальные же сообщения, как им и полагается, ничуть не заботятся о том, что и как делается
объектами, они вольны воспринимать их как угодно.
· Графическая оболочка MeeGo
Графическая оболочка представляет собой, в целом, оконный менеджер и набор базовых
графических приложений. В ОС MeeGo графическая оболочка представлена в трех вариантах,
имеющих значительные различия: IVI Meego, Netbook uX и Handset uX. Фреймворк Qt предоставляет
единый интерфейс, который позволяет создавать приложения, способные работать в любом из этих
вариантов графической оболочки. Тем не менее следует отметить, что для создания приложений
хорошо интегрированных в графическую оболочку версии Handset uX необходимо использовать
фреймворк meegotouch. Необходимо учесть, однако, что интерфейс meegotouch не входит в Core API
MeeGo и может быть подвержен значительным изменениям.
Опишем в общих чертах устройство графической оболчки версий Handset и Netbook uX.
Графическая оболочка Netbook uX очень похожа на графическую оболочку ОС Moblin. В качестве
оконного менеджера, как и в Moblin, используется mutter. Netbook uX поддерживает библиотеки GTK
и clutter, позволяющую использовать возможность акселерации двумерной графики.
В Handset uX функции оконного менеджера исполняет mcomposite. За стартовый экран
графической оболочки отвечает meegotouchhome.
Страницы
- « первая
- ‹ предыдущая
- …
- 64
- 65
- 66
- 67
- 68
- …
- следующая ›
- последняя »
