СОздание приложения

В традициях LUWRAIN простейшее приложение на Java должно состоять из следующих компонентов:

  1. Класса App, который должен наследоваться от класса org.luwrain.app.base.AppBase.
  2. Класса MainLayout, который должен наследоваться от класса org.luwrain.app.base.LayoutBase.
  3. Класса Extension, который должен наследоваться от класса org.luwrain.core.EmptyExtension.
  4. Класса или интерфейса Strings, который отвечает за локализацию.

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

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

Приложением является потомок от AppBase, который берёт на себя кучу чёрной работы. Он должен содержать метод onAppInit(), который возвращает стартовый layout. layout - это комплект областей на экране. layout должен быть наследником от LayoutBase и вызывать метод setAreaLayout(), который задаёт экземпляры областей. Если нужно сменить набор областей, то у app можно вызывать метод setAreaLayout().

AppBase попутно управляет фоновыми задачами. То есть это такие задачи, в ходе выполнения которых пользователь слышит характерный фоновый звук, обозначающий, что компьютер что-то делает. Этот класс их трекает, и если пользователь нажал Escape, то никогда не будет вызвана функция finishedTask(), которая передаёт в основной поток результат выполнения фоновой задачи.

Следует отметить, что часть работы можно делать вручную. Больших трудов потребовал поиск компоновки кода, когда можно писать только ровно самое необходимое. В частности, можно не пользоваться функцией Layoutbase.setAreaLayout(), а все области поддерживать вручную, включая обработку Tab для прыжка между ними, чего в простом варианте делать не нужно.

Более того, AppBase и LayoutBase тоже не являются необходимыми. Это очень сильная упрощалка функций ядра системы, которые полностью скрыть нельзя, поскольку это привело бы к потери свободы делать какие-нибудь редкие, но всё же иногда нужные задачи. Тем не менее, использование AppBase и LayoutBase очень жёстко рекомендуется, потому что они создают максимально единообразное поведение для пользователя. Нынешний LayoutBase - результат относительно свежий, поскольку туда собрались все теперь исправленные грабли, собранные на попытках создания приложений.

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

Ещё также при запуске в linux есть ключ –linux-input-fifo, который задаёт имя файла, откуда LUWRAIN будет постоянно читать команды. Этот файл надо предварительно создать через mkfifo, а далее в него можно кормить команды через echo foobar > /tmp/luwrain.fifo. Если туда скормить command reader, откроется читалка.

Это позволяет делать удалённое управление системой от всяких нестандартных клавиш. Для работы с мультимедийной клавиатурой можно использовать xbindkeys. Я играл так, довольно удобно. Про bluetooth не в курсе, но тоже какие-нибудь такие хуки там есть, наверное.

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

© 2012–2024 Проект LUWRAIN
Дизайн от Strash