LINUX.ORG.RU

Генератор утилит из DBus интерфейса.

 , ,


0

2

Представьте вы пишете приложение, например очередной музыкальный плеер. Так вот, вам достаточно определить DBus сервис и методы в нем, а какое-то приложение интроспектирует методы и согласно конфигу генерирует клиентские утилиты, которые предоставляют удобный доступ в этому интерфейсу.

Вы написали методы сервиса lorplayer - PlayArtists, Volume и Stop. Сразу создана утилита lorplayer которая работает вот так

lorplayer play-artists "Brutto" "SkaP"
...
lorplayer stop

Первый вызов через механизмы DBus запускает демон, который подключается к Last.FM, Youtube, VK, Google Music, Spotify и начинает играть музыку из скомпонованого плейлиста. Возможно сам демон подключается по DBus к панели вашего DE и пишет Now Playing. В вашем DE комбинации подключены к lorplayer volume +10, lorplayer volume -10.

Как решит автор приложения, но например после lorplayer stop приложение еще может висеть в памяти 10 мин на случай если стоп временный и включат что-то новое.

Как вам такая прозрачность?

★★★★★

мне показалось, или из dbus интерфейса генерируют код все кому не лень? и генерировать ещё один парсер командной строки и код вызывающий dbus метод это дело на несколько часов, причем как runtime или скомпилированный..

qnikst ★★★★★
()
Ответ на: комментарий от vertexua

Ну для начала есть стандарт MPRIS2.0, а для него полно готовых приблуд в разных DE - вдруг ты не знал. Хотя MPRIS - это не очень «максимально просто и удобно».

fenris ★★★★★
()

С помощью DBus гораздо удобнее делать другие вещи, кмк. Например, разбить плеер на два приложения: собственно проигрыватель и искалку музыки в социалочках. Причём искалка сможет воспроизводить найденное через любой плеер с поддержкой MPRIS2. Типа такого.

fenris ★★★★★
()
Ответ на: комментарий от fenris

MPRIS

Спасибо, но медиа плеер - только пример, может быть что угодно, компилятор, регулятор яркости экрана

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

во всех языках, что я видел сишные, питоно, луа-байндинги, была генерилка классов, генерилка программы/рантайм парсера в общем-то +1 шаг. У нас для хацкеля есть генерилка парсеров командной строки и файлов конфигурации по разным входным форматам, туда можно прикрутить и вход по схеме интерфейса, но пока она закрыта, я спрошу если ли шанс на её открытие.

Как я понимаю, приложению обычно проще сгенерить класс и встроить в программу, чем иметь сгенерированную standalone утилиту, и вообще все эти standalone утилиты пытаются банить объявлять дедовским устаревним unix-way-ем, который тормозит и не работает :)

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от qnikst

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

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

не спорю. я не считаю, что подход с запуском легковесного приложения на C и таким образом образованный unix-way это плохо. Единственная проблема тут это отсутсвие «проверки типов», и твоё приложение формально должно генерировать код, как запускать эту утилиту, а в этом случае почему бы не сгенерировать код для пинания dbus сразу.

Естественно как клей для общения с пользователем или интеграцией в DE/WM этот вариант хорош, если WM это не awesome или xmonad и т.п., которые конфигурируются через пересборку.

Вообще я бы был не против увидеть такую утилиту в public коде.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Единственная проблема тут это отсутсвие «проверки типов», и твоё приложение формально должно генерировать код, как запускать эту утилиту, а в этом случае почему бы не сгенерировать код для пинания dbus сразу.

Я вот тут не совсем понял, ну она будет генерировать --help и код, который будет в более короткой форме пинать DBus.

Мой WM - i3, там все конфигурируется отлично, просто, быстро, панели можно создавать из обычных консольных утилит, выплевывающих в консоль json, с цветами, поддержкой мыши. Легко к такому демону пишется и DBus интерфейс.

http://i3wm.org/docs/i3bar-protocol.html

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Я вот тут не совсем понял, ну она будет генерировать --help и код, который будет в более короткой форме пинать DBus.

я лично разницы между exec("someutil play-artist \"Neun Welten\"), и dbus.send("someutil", {"command":"playartist", "name":"Neun Welten"); не вижу, особенно если ЯП поддерживает генерацию кода, типа хацкельного QuasiQuotes, типа [dbus| $(generateCommandFromInterface "someutil" "play-artist") "Neun Welten"|]. Если можно написать первое, то можно сразу сгенерировать и второе оно ещё и тайпчекнется.

Если проблемы в гарантии консистентности и изменения интерфейсов нет, то неплохой вариант.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Я думаю что ради комфорта пользователей лучше придерживаться принятых в Unix форматов, хотя может это вопрос привычки и эстетики.

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

exec

Если вызывать из другого приложения, то ясно что лучше дергать dbus напрямую, я имел ввиду управление из консоли. У многих людей всегда открыт терминал, они в нем работу работают. Или у них есть какой-то выплывающий по комбинации клавиш терминал.

vertexua ★★★★★
() автор топика
Ответ на: комментарий от qnikst

Ещё есть qdbus с запуском вида: qdbus <программа> <интерфейс> <функция>

Тем более для него ещё автодополнение как правило работает.

fenris ★★★★★
()

а какое-то приложение интроспектирует методы и согласно конфигу генерирует клиентские утилиты, которые предоставляют удобный доступ в этому интерфейсу.

Зачем генерировать утилиты, если можно сделать одну, которая интроспектирует методы во время исполнения? Понаделать на неё симлинков и разрешать через argv[0].

i-rinat ★★★★★
()
Ответ на: комментарий от vertexua

Так можно дойти до того, что всё в мире — техническая деталь.

i-rinat ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.