andreydedukhin / Арго графический пользовательский фреймворк
CI/CD
Реестр контейнеров и пакетов

Applications.md

Арго Фреймворк Википедия

Содержание

Приложения Фреймворка

Сам по себе фреймворк не содержит ни единого встроенного приложения и, по сути, без них бесполезен. Всю полезную работу для создания качественного графического интерфейса выполняют приложения, используя API (Application Program Interface) фреймворка.

Приложения фреймворка могут классифицироваться по разным признакам - это системные или пользовательские приложения, оконные или фоновые, по режиму запуска: статические, динамические или запущенные в отдельном процессе (remote). Ниже будут рассмотрены все эти варианты.

Фреймворк имеет раздельные механизмы описания для пользовательского интерфейса и логической части приложения. Пользовательский интерфейс (окна приложения) прописываются в конфигурационных XML файлах приложения, в то время как логическая часть пишется на C/C++/Python языках.

Системные и Пользовательские Приложения

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

  • Такие приложения всегда предустанавливаются и не могут быть удалены из системы. Предустановка выполняется в конфигурационном описании системы и размещением файлов приложения по некоторым заданным правилам.
  • Системные приложения обладают расширенным набором привилегий, которые позволяют им взаимодействовать с системным API фреймворка и получать системную информацию для ряда операций: запускать или закрывать другие приложения, получать информацию о файловой системе, работать с системными нотификациями и многое другое. Системные приложения могут автоматически запускаться системой, в то время как пользовательские такой привилегией не обладают. Пользовательские приложения тоже имеют некие привилегии, например, могут запускаться только в единственном экземпляре (singleton). Подробнее о привилегиях будет рассказано позже.
  • Система может иметь несколько дисплеев и также несколько виртуальных суб-дисплеев. Системное приложение может создавать несколько окон в различных парах дисплей/суб-дисплей. Пользовательское приложение может создавать свои окна только в дисплее/суб-дисплее по умолчанию.

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

Оконные и Фоновые Приложения

Как понятно из названия, оконные приложения имеют как минимум одно окно, которое может увидеть пользователь. Окна приложений описываются в конфигурационных XML файлах приложения (все XML файлы фреймворка имеют расширение FML - Framework Markup Language, есть некоторые отличия от XML). Фоновые приложения таких описаний не имеют, и соответственно, никогда на дисплее не отображаются. Только системные приложения могут использовать такой режим. Пользовательские приложения должны иметь хотя бы одно окно.

Режимы Запуска Приложений

Фреймворк поддерживает три основных режима запуска приложений:

  • Статический
  • Динамический
  • Удаленный

Статический режим подразумевает, что логическая часть приложения статически слинкована с исполняемым модулем фреймворка. Это возможно только при сборке исполняемого модуля и, поэтому не приемлемо для пользовательских приложений (ну можно, конечно, обойти. Но зачем? Для отладки приложений в SDK, например).

Приложение в динамическом режиме представляет собой динамическую загружаемую библиотеку (DLL - Dynamic Load Library). При старте приложения библиотека подгружается, и далее все работает как и в случае статической библиотеки. Пользовательские приложения могут быть динамическими, но это только пока и только для SDK.

Удаленный режим подразумевает запуск приложения в другом процессе. При этом пользовательский интерфейс по прежнему обрабатывается фреймворком, в то время как логическая часть находится в другом процессе. Приложение при этом строится как исполняемый бинарный файл. Обмен информацией между приложением и фреймворком производится по некоторым IPC (Inter Process Communication) протоколам, в частности, SDK может использовать TCP/UDP IP соединения для управляющей информации и разделяемую память для передачи больших объемов данных. В удаленном режиме может работать любое приложение, если время обмена данными с фреймворком не имеет существенного значения.

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

Использование статического или динамического режима запуска приложения полезно для максимального быстродействия приложений. Но при этом приложение работает в адресном пространстве фреймворка и в случае креша приложения… фреймворк не покрешится, как вы ожидали, но тут есть определенные нерешенные проблемы.

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

Привилегии Приложений

Привилегии приложений предназначены в первую очередь для разграничения возможностей системных и пользовательских приложений при управлении системой. Пользовательские приложения не имеют возможности вмешиваться в системные процессы, поэтому соответствующие привилегии им не доступны (системное приложение должно быть предустановлено, иначе привилегий не получить). Однако, некоторые привилегии пользовательским приложениям все же доступны. Привилегии представляют собой битовые флаги, разделенные на три диапазона: привилегии пользовательских приложений (биты 0 - 7); привилегии системных приложений (биты 8 - 23, также доступен и диапазон 0 - 7); диапазон отладочных приложений (биты 24 - 31, все остальные тоже доступны). В SDK диапазон отладочных приложений не доступен, но позднее может быть добавлен специальный маркер в коде приложения, чтобы этот диапазон включать. Код таких приложений будет закрыт, так же как закрыт код отладочного терминала (dbgshell) сейчас. Отладочный терминал не предоставляет всех возможностей в SDK сейчас, поскольку соответствующий диапазон заблокирован.

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

Расширения Приложений

Расширения приложений предназначены для динамического подключения/отключения окон, обработки событий от этих окон и передачу сообщений в приложение, к которому подключены в текущий момент. Основным в расширении является окно, логическая часть минимальна и используется только для настроек виджетов окна в процессе подключения. Расширения реализуют некий общеупотребительный интерфейс, который может использоваться разными приложениями: выбор цвета (color picker), выбор даты/времени, вывод сообщений и для прочих целей. Окно (или окна) расширений создается один раз при старте системы и может быть использовано многократно в разных приложениях, что унифицирует интерфейс и экономит много оперативной памяти. Это напоминает о функциональности, реализуемой приложениями-сервисами, по сути является аналогом, но главное отличие в том, что расширение, в отличие от сервиса, существенно проще. Расширения реализуют простые функции, которые не требуют доступа к системной информации, это просто диалоговые окна, которые приложения могут вызвать независимо от их привилегий. Сервисы всегда требуют неких привилегий и реализуют сложный функционал (например, сервисы FileView или System Alert). Для расширений проще: получил запрос - отдал результат, полученный из окна. Выигрыш в использовании расширений еще и в том, что они не требуют дополнительных програмных потоков (threads, приложения используют как минимум два, а то и три), они используют потоки приложения, к которому подключены, и это также экономит память.

Как уже понятно, расширения сильно отличаются от приложений. Перечислю основные отличия:

  • Расширения всегда бывают только системными. Они инициализируются при запуске системы и никогда, ни при каких условиях, не выгружаются.
  • Расширения всегда бывают в единичном экземпляре, т.е. в singleton режиме.
  • Расширения всегда имеют, как минимум, одно окно (могут иметь и несколько, но это, извините, моветон, на мой взгляд).
  • Расширение не может быть запущено в отдельном процессе, только в динамическом или статическом режиме. Поэтому использование Python для них неприемлемо, только C/C++.
  • Коллбеки расширений не защищены механизмом обработки исключений в отличие от статических и динамических приложений (на то есть причины, но, возможно, это будет исправлено в дальнейшем).
  • Расширение не может иметь своего собственного публичного идентификатора, он всегда тот, который присвоен приложению, к которому расширение подключено. Приватный (установочный) идентификатор у него есть.

Структура окон расширений практически ничем не отличаются от окон приложений. На данный момент есть только одно отличие - нельзя использовать встроенные кнопки стиля (для минимизации окна или выхода). Эти кнопки имеют особый статус и посылают некоторое событие в приложение, но расширение этого события не получит. Это приводит к ошибкам в процессе работы, для расширения эти события неприменимы (да и надо вам чтобы раширение закрыло приложение? Думаю нет.). Расширение может только получить событие, по которому произойдет его автоматическое отключение, и, соответственно, скрытие его окна.

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

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

Ссылка на вики репозиторий
Арго графический пользовательский фреймворк WIKI
Ссылка на вики репозиторий
Арго графический пользовательский фреймворк WIKI