В традициях LUWRAIN простейшее приложение на Java должно состоять из следующих компонентов:
App, который должен наследоваться от класса org.luwrain.app.base.AppBase.MainLayout, который должен наследоваться от класса org.luwrain.app.base.LayoutBase.Extension, который должен наследоваться от класса org.luwrain.core.EmptyExtension.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. А так да, замечательная мысль. Логика в этом есть.