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

Часть I. Краткий обзор OBOS App_Server

Недавно, я попросил DarkWyrm дать мне быстрый краткий обзор app_server. Это часть OBOS, которую я действительно не понимаю; я хотел посмотреть на исходный код, и я искал введение, которое помогло бы мне. DarkWyrm обеспечил большую часть этой статьи; моя работа была главным образом редакционная + немного разъяснений и введений, чтобы сделать это более похожим на NewsLetter.

app_server — процесс в BeOS, который отвечает за работу приложений. Это работает в пользовательском режиме, а не на уровне ядра. Приложения связываются с app_server через Interface Kit (далее IK). IK контролирует весь процесс — полосы прокрутки, кнопки, группы текста, и т.д. — и обращается к app_server, чтобы рисовать. Также, я уверен, что Вы поймёте, что app_server — сложная часть системы. Производительность и многопоточность являются обязательными требованиями к его успеху. Подобно любму другому классу программного обеспечения, это входит в логические рамки подсистем и различных классов, чтобы было удобство для разработчиков. Для app_server, эти подсистемы — Шрифты, Рабочий стол, Управление, Графика, и Поддержка.

Шрифты

Отображение шрифтов нам обеспечивает FreeType2 (FT2). FT2 — полноценная, открытая система отображения шрифтов, которая используется во многих других системах. Разработчики FT2 спасли наше времени и усилия, за что им большое спасибо. Подсистема Шрифтов технически небольшая, т.к ограничена только несколькими классами: FontServer, FontFamily, FontStyle, и ServerFont. Главный компонент, управляющий выводом шрифтов — FontServer. Когда app_server запустилсяr, сервер шрифтов сканирует директорию, в которой находятся шрифты, и создает список доступных шрифтов используя соответствующие классы. Большую часть работы над шрифтами для OBOS составляет ServerFont, который эквивалентен серверу BFont. Почти любые объекты, которые работают со шрифтами, должны использовать ServerFont. Разработка подсистема шрифтов уже завершена.

Рабочий стол

Рабочий стол, в этом случае, не относится к OpenTracker, папкам, или Deskbar. Он является частью app_server, которая имеет дело с окнами, управляя монитором(ами) и областью рисования, и “clipping” — только рисунок, который действительно видимый. OBOS Рабочий стол, главным образом, организован иерархически относительно класса stucture. Класс рабочего стола — главный, т.к. он выполняет задачи высокого уровня, типа загрузки и инициализации драйвера видеокарты, обработки фокуса окна, посылка входящих сообщений соответствующему оброботчику, и управление данными глобальных функций API подобно set_scroll_bar_info () и т.п.. За рабочим столом идёт — объект RootLayer, который выполняет две задачи: это управляет всеми подслоями и держит доступный ServerScreen и объекты Рабочего пространства (aka Workspaces). Далее идёт ServerScreen, который в этом пункте используется немного, но составляет основу для поддержки мультимониторинга. Здесь он является как бы домом для объекта DisplayDriver. Также на третьем месте по управлению — WinBorder класс, который обеспечивает управление объектами окна в иерархии экрана. В то время как каждый объект WinBorder технически имеет его собственный декоратор (aka Decorator), объект декоратора дает WinBorder форму согласно свойствам окна, установленным в декораторе. Самый низкий эшелон иерархии занят объектами cлоя. Слои — обеспечивают основной код для перерисовки и обрезания для WinBorder и его подклассов. ColorSet занимается обработкой цветными атрибутами рабочего стола, такими как цвет таба (Windows Tab — жёлтая полоса с названием окна), цвет фона панели, и т.д. Это написано так, чтобы исходный код был совместим с Dano. Если это окажется проблемой с бинарной совместимостью, то наши усилия будут направлены на достижение бинарной совместимости. SysCursor — это надстройка над ServerBitmap, которая отвечает за данные BCursor.

Управление

Управление относится главным образом к обработке сообщений — установление связи app_server с другими процессами системы, которые должны быть с ним (с app_server) связаны. Классы, которые управляют — это AppServer, ServerApp, ServerWindow, SessionStreamReader, BitmapManager, и CursorManager. AppServer выполняет основные задачи запуска: создаёт дополнительные потоки, загружает соответствующий декоратор, и генерирует глобальные объекты управления. Как только инициализация системы завершена, он наблюдает за работой некоторых видов сообщений — главным образом создание приложений, но также и для закрытия сервера когда он работает в испытательном режиме. Потоки создают Poller и Picasso — сообщения входного процесса и проверка на мертвые приложения. ServerApp объекты — «коллега» BApplications и обеспечивают обработку сервисов BApplication. Порты их сообщения также используются для глобальных запросов функций и создания ServerWindows. ServerWindows — «коллега» BWindows, обрабатывает запросы BWindow. Графические сообщения транслируются в запросы DisplayDriver его DispatchGraphicsMessage методом. ServerWindow использует SessionStreamReader для обработки графических сообщений, т.к. графические сообщения разбиваются на потоки — кешируются(точного перевода не знаю, вот оригинал — cached -–прим. автора) клиентом и посылаются в блоки, когда «хранилище» кеша заполняется или когда требуется синхронизация. Необходимо заставить это мирно работать вместе с нормальными протоколами сообщений на основе запаковки без катастрофических результатов, появляющихся время от времени. BitmapManager обеспечивает размещение и освобождение ServerBitmaps и буферной памяти, связанной с ними. CursorManager следит за всеми ServerCursors, используемыми системой. Это также обеспечивает сервисы нового System Cursor API, что является залогом консистенции и гибкости GUI.

Графика

Вся подсистема опирается на DisplayDriver класс, который обеспечивает графический интерфейс. Это учитывается при тестировании, передавая к DirectWindow, WindowScreen, или BBitmap/BView дополнительные комбинации, чтобы можно было использовать правильные аппаратные средства ЭВМ и ускорение аппаратных средств ЭВМ. Здесь есть одно отличие от R5 — аппаратные курсоры не поддерживаются, а используют программный курсор, который намного более гибкий. Будут использоваться аппаратные курсоры по причине: старшие видеокарты, особенно которые работают без ускоренного блитирования, нуждаются в повышении скорости работы. Современные видеокарты не нуждаются. API использования 32 битного курсора не является в настоящее время приоритетом, и работа над отложится до R2. PNGDump выполняет одну функцию и используется для сохранения содержания framebuffer в PNG файл. Это заменяет огромный BMP, который создаёт app_server в R5. DisplayDriver использует PatternHandler для конвертирования в (x, y) координаты. ServerPicture используется для поддержки сервера BPicture. Довольно много работы необходимо сделать, чтобы осуществить поддержку BPicture. Объекты декоратора используются для определения и рисования границ и табов(Window Tab -–прим. переводчика) каждого окна. Сервер также содержит свой собственный декоратор, для того чтобы система могла функционировать, даже если никакие декораторы не установлены.

Поддержка

Эти классы не связаны ни с какой из четырех групп.

• Globals.h содержит определения типов окна, и будет вероятно иметь больше определений и вещей в будущем.
• Angle обеспечивает разумно быстрое средство для получения функциональных значений для углов (angles -–прим. переводчика) через таблицу поиска. Это в настоящее время необходимо только для внутреннего использования DisplayDriver.
• ServerProtocol.h обеспечивает определение кода сообщения для соединений сервера.
• SharedObject.h вероятно станет основой для ServerBitmap в будущем.
• CursorData определяет стандартный курсор системы. Это использует только CursorManager.
• TokenHandler обеспечивает простое получение символов с выбором, чтобы исключать значения.
• RGBColor — определяет цветовую гамму( в 8–, 15–, 16–, или на 32 бита).
• Utils — работает с кодом сообщения и BMessages.
• RectUtils содержит функции для исправления ошибок в работе с BRegions и BRects в R5. Этот файл исчезнет, после того, как R1 будет выпущен.
• ServerBitmap — «коллега» BBitmap. Это также служит основой для ServerCursor. ServerBitmaps непосредственно не создаётся или разрушается, когда используется для поддержки BBitmap.
• areafunc.c и bget.c обеспечивают BGET, который распределяет функции, чтобы соединять это с BeOS областями.
• FMWList содержит класс списка для управления плаванием(floating -–прим. автора) и модулированием окнами.
• ServerConfig.h — файл, использующийся для конфигурации сборки app_server.

app_server (очевидно) прогрессировал, даже считая опытные образцы. Усилия Гейба, Adi, DarkWyrm и их товарищей по команде будут оценены!

Адрес оригинальной статьи: http://open–beos.sourceforge.net/nsl.php?mode=display&id=51