LINUX.ORG.RU

luastatus — генератор данных для панелей состояния, поддерживающий i3bar и dwm

 , , , ,


5

4

Вышла первая версия luastatus — универсального генератора данных для панелей состояния, поддерживающего i3bar и dwm. Программа написана на C и распространяется под лицензией GNU LGPL v3.

Большинство генераторов данных для панелей состояния тайловых WM либо обновляют информацию по таймеру (например, conky), либо требуют сигнал для перерисовки (например, i3status). Панели же в составе окружений рабочего стола, как правило, обновляют информацию мгновенно и автоматически, как и luastatus.

luastatus работает с загружаемыми модулями двух типов: плагины (отвечают за работу с каким-либо источником событий) и так называемые barlib’ы (отвечают за работу с конкретной панелью состояния).

Схема работы luastatus следующая:

  • Один из плагинов сообщает, что произошло какое-то событие, и генерирует описывающий его Lua-объект.
  • Вызывается пользовательская функция (widget.cb) с этим объектом в качестве аргумента.
  • Возвращённое ей значение передаётся в barlib.

Также barlib может оповестить программу-виджет о том, что с виджетом произошло какое-либо событие. В таком случае barlib также генерирует Lua-объект, описывающий это событие, и пользовательская функция (widget.event) вызывается с ним в качестве аргумента. Например, barlib для i3 сообщает, когда пользователь нажал на виджет, а также передаёт информацию о том, какой кнопкой было сделано нажатие, и его координаты.

На данный момент реализованы следующие плагины:

  • alsa — следит за изменением громкости канала ALSA.
  • fs — генерирует события по таймеру, передаёт виджету информацию о количестве занятого места в файловой системе. Также поддерживается wake-up FIFO.
  • mpd — следит за громкостью и текущим плейлистом mpd.
  • pipe — запускает процесс и генерирует событие каждый раз, когда он выводит в stdout строку (можно указать другой разделитель вывода). Эта строка передаётся виджету.
  • timer — просто генерирует события по таймеру (например, для виджета-часов или виджетов, читающих какие-то файлы в /proc). Также поддерживается wake-up FIFO.
  • xkb — следит за текущей раскладкой клавиатуры и передаёт виджету номер группы активной раскладки и её имя.
  • xtitle — следит за текущим активным окном и сообщает его заголовок.

И следующие barlib’ы:

  • i3;
  • dwm.

>>> Страница проекта на GitHub

>>> Страница релиза



Проверено: anonymous_incognito ()
Последнее исправление: sudopacman (всего исправлений: 2)

Не собирается

[100%] Linking C executable luastatus
[100%] Built target luastatus
make[2]: *** Нет правила для сборки цели «plugins/alsa/CMakeFiles/alsa.dir/build».  Останов.
CMakeFiles/Makefile2:284: ошибка выполнения рецепта для цели «plugins/alsa/CMakeFiles/alsa.dir/all»
make[1]: *** [plugins/alsa/CMakeFiles/alsa.dir/all] Ошибка 2
Makefile:127: ошибка выполнения рецепта для цели «all»
make: *** [all] Ошибка 2

UPD: собралось после

sudo ln -s $(pwd)/../luastatus /usr/local/lib/luastatus

Что за трэш?

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

Понятия не имею, УМВР. cmake --version, cmake --debug-output ., что вообще делал?

$(pwd)/../luastatus

Ты откуда чего собираешь-то?

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

Fixed. Ошибка была довольно глупая, не понимаю, почему мой CMake на это не ругался.

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

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

Ну и возможности по кастомизации довольно ограничены, а тут — Lua же!

shdown
() автор топика

Т. е. оно юзает всякие там inotify на файлах в /proc и нативно коннектится к иксам, слушая его события? Или на самом нижнем уровне оно всё-таки поллит?

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

Нет, inotify пока не юзает, но можно запилить такой плагин.

run() каждого плагина запускается в отдельном потоке; плагин может сказать: «произошло некоторое событие, хочу отправить виджету Lua-объект». Да, плагины xkb и xtitle «нативно коннектятся к иксам, слушая его события».

shdown
() автор топика

Не собирается с lua-5.1.5

-- Checking for one of the modules 'lua53;lua-5.3;lua5.3;lua52;lua-5.2;lua5.2;lua51;lua-5.1;lua5.1;luajit'
CMake Error at /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:574 (message):
  None of the required

ashot ★★★★
()

в отдельноп потоке

Ой вэй, то есть на десять виджетов десять потоков? Печально, в lua нет нормальной поддержки concurrency?

lua

Закопать

следит за текущей раскладкой клавиатуры и передаёт виджету номер группы активной раскладки и её имя.

Ну это не i3-way совсем. Ты раскладку переключаешь шорткатом, проще вместе с этим послать сигнал панельке, а та пусть дернет простую команду. В i3blocks сделано проще, имхо.

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

Ой вэй, то есть на десять виджетов десять потоков?

Да.

Печально, в lua нет нормальной поддержки concurrency?

Нет, и это by design.

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

Да.

Тебя не смущают затраты на переключение контекста для такой простой задачи? Почему не накостылить простой ивентлуп?

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

Тебя не смущают затраты на переключение контекста для такой простой задачи?

Посмотрел на календарь. Нет, вроде действительно 2017 год, а не 1977.

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

Посмотрел на календарь. Нет, вроде действительно 2017 год, а не 1977.

Ну а смысл подобного тогда? Заменить отдельные процессы/скрипты на кучу потоков с луа — делать менее гибкое решение. Теперь вместо шелл скрипта мне нужно пилить какие-то либы. Какой тогда профит от запихивания всего в один процесс?

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

На это возразить нечего

Это у топикстартера надо спрашивать.

Deleted
()
Ответ на: комментарий от Freyr69

Я думал об этом. Сильно усложнит архитектуру, плюс виджетам (а имеено, функции cb) должно быть позволено блокировать, а с таким подходом это никому не мешает.

менее гибкое решение

Зато более удобное — почти всё сделано за тебя, тебе же осталось только получить готовые данные и возвратить какой-то объект, понимаемый barlib’ом.

мне нужно пилить какие-то либы

Ты про плагины? К какому-то моменту их количество, я надеюсь, будет достаточно для того, чтобы ничего пилить не нужно было.

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

почти всё сделано за тебя

У меня скрипт для раскладки и альсы по одной строке для i3blocks.

Ты про плагины? К какому-то моменту их количество, я надеюсь

Так а в чем их профит по сравнению с шелл скриптами, которые тоже искаропки есть для i3blocks? Кроме того, что я ограничен одним (невероятно убогим) луа, когда для i3blocks можно скримты пилить на чем угодно, хоть на OCaml или Haskell?

https://github.com/vivien/i3blocks/tree/master/scripts

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

У меня скрипт для раскладки и альсы по одной строке для i3blocks.

Покажи.

Так а в чем их профит по сравнению с шелл скриптами

В том, что он не форкается без надобности и обновляется не только по таймеру.

https://github.com/vivien/i3blocks/tree/master/scripts

Ну, так тебе сказать…

$ wget -nv https://raw.githubusercontent.com/vivien/i3blocks/master/scripts/volume
2017-01-18 15:29:48 URL:https://raw.githubusercontent.com/vivien/i3blocks/master/scripts/volume [2738/2738] -> "volume" [1]
$ countforks bash volume
18
Предлагается так делать каждые N секунд или какой-то сигнал слать? Вот нужно тебе при каждом изменении громкости девятнадцать форков делать (ещё же сам bash нужно запустить), в т.ч. вызывать perl (!!!)?

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

Покажи.

Звук:

amixer get Master | grep -E -o '[0-9]{1,3}?%' | head -1

Клава:

xkb-switch

какой-то сигнал слать?

Да, при изменении громкости шлешь сигнал.

Вот нужно тебе при каждом изменении громкости девятнадцать форков делать

Ну ты ж создаешь 10 потоков. fork в линуксе очень легкий.

в т.ч. вызывать perl (!!!)?

Тебе никто не мешает написать программу хоть на сях. Тогда даже баш запускать не нужно, как в случае с xkb-switch.

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

а баш-скрипты норм.

Там не баш-скрипты, а процессы. Процессом может быть хоть скрипт на любом языке, хоть не скрипт. Да, процессы — норм, а потоки с луай — не норм.

видите-ли

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

Ну ты ж создаешь 10 потоков

Один раз создать 10 потоков и дёргать каждый раз Lua-функцию — гораздо менее затратно, чем плодить процессы каждый раз.

xfce4-panel, например, по процессу на виджет держит — и никто не жалуется. Подозреваю, что панели остальных DE также держат либо поток, либо процесс на виджет.

И костылей гораздо меньше — не нужно никому посылать никакие сигналы, парсить что-то шеллом, etc.

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

Потоки в сотни раз(а то и больше) эффективнее процессов. И никакое переключение контекста не замедлит их до уровня процессов, и тем более баша.

Для примера, просто приложение с использованием QtCore потратит порядка 1М инструкций только на линковку и инициализацию. За это же «время» можно наплодить и убить сотни потоков.

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

Потоки в сотни раз(а то и больше) эффективнее процессов.

В линуксе? Не знаю, не уверен. В линуксе потоки — те же процессы, но с общим адресным пространством, разве нет? Можно пруфов про сотни раз?

QtCore потратит порядка 1М инструкций только на линковку и инициализацию.

Это-то тут при чем?

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

xfce4-panel, например, по процессу на виджет держит — и никто не жалуется.

Позвольте спросить, а нахрена?

Подозреваю, что панели остальных DE также держат либо поток, либо процесс на виджет.

В gtk это бессмысленно. Ивент-луп гуя в главном потоке.

Deleted
()
Ответ на: комментарий от Freyr69

В линуксе? Не знаю, не уверен. В линуксе потоки — те же процессы, но с общим адресным пространством, разве нет? Можно пруфов про сотни раз?

Переключиться на другую таблицу страниц vs не переключаться на другую таблицу страниц. Не сложно понять, что быстрее.

Deleted
()
Ответ на: комментарий от shdown

каждый раз Lua-функцию — гораздо менее затратно, чем плодить процессы каждый раз.

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

что панели остальных DE также держат либо поток, либо процесс на виджет.

А еще они общаются с процессами через dbus какой. Только зачем это в тайлинговых де?

И костылей гораздо меньше — не нужно никому посылать никакие сигналы, парсить что-то шеллом, etc.

Так а кто тебе мешает написать такой же плагин в виде бинарника для i3blocks? Не нужно ничего парсить шеллами, я же не разбираю вывод xkb-switch, он сразу возвращает то, что нужно.

посылать никакие сигналы

Ну от ipc-то никуда не денешься, а это все лучше dbus.

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

Переключиться на другую таблицу страниц vs не переключаться на другую таблицу страниц. Не сложно понять, что быстрее.

Не, все-таки хотелось бы про сотни раз.

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

Напишите бенч.

Ну привет. Может мне и доказывать сразу чужие утверждения? Наверное, цифра в сотни раз не с потолка взялась, а из каких-то бумажек?

Что-то мне сдается, что даже очень хитрый вызов clone такой разницы не даст.

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

Позвольте спросить, а нахрена?

А там вроде каждый плагин запускается как отдельное приложение в трее.

В gtk это бессмысленно. Ивент-луп гуя в главном потоке.

Я не понял. Предлагается, чтобы каждый плагин файловые дескрипторы и время, через которое нужно ещё раз его дёрнуть, если на этих дескрипторах ничего не будет, отдавал? А основная программа будет их poll’ить? А при чём тут gtk и его «ивент-луп»?

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

гибкость

В чём заключается гибкость? Из Lua ты тоже можешь форкнуться девятнадцать раз. И есть плагин pipe, который вызывает твою функцию, как только процесс напечатал строку. Можешь xkb-switch так запустить, например (только уже плагин xkb есть).

Каждый раз — это раз в минуты.

Это верно не для всех источников событий и вообще костыльно.

Очень даже достойная цена за гибкость, ящитаю. Все-таки писать плагины для панельки на сях/луа — то еще занятие.

Я всё никак не пойму, что ты там собрался писать на сях. Плагины? Какие?

А Lua прекрасно подходит для такой фигни, я считаю.

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

Там мерять нужно не только fork, но и exec.

Смотря какая цель ставится.

Deleted
()
Ответ на: комментарий от shdown

В чём заключается гибкость?

В том, что у меня есть SCADA система, и я могу написать плагин для мониторинга на баше/си/крестах/sml/удобном языке и дергать процесс по определенным событиям.

В твоем случае я должен писать на луа? На сях? А если оно работает через дбус, мне дбус интерфейс в си/луа городить?

Это верно не для всех источников событий и вообще костыльно.

Костыльно запускать процесс для обработки события? В юниксе это традиция, так-то: пайпы, форкающиеся сервера, ipc.

А Lua прекрасно подходит для такой фигни, я считаю.

А я не считаю.

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

А там вроде каждый плагин запускается как отдельное приложение в трее.

«Как в трее» - это надо сделать fork, создать своё окно и попроситься, чтобы панель его зарепарентила.

В принципе, что-то подобное там наверное и происходит, т.к. я запустил панель, и у неё 3 дочерних процесса.

Я не понял. Предлагается, чтобы каждый плагин файловые дескрипторы и время, через которое нужно ещё раз его дёрнуть, если на этих дескрипторах ничего не будет, отдавал? А основная программа будет их poll’ить? А при чём тут gtk и его «ивент-луп»?

gtk тут при том, что у тебя гуй самой панели на gtk, и гуй плагина на gtk. Если они существуют в одном процессе, они должны работать в одном потоке (собственно - в главном потоке) в общем цикле событий. По-другому gtk не умеет. Если ты хочешь свой гуй держать отдельно, то см выше про fork. :-)

Ты, разумеется, можешь создавать потоки для выполнения асинхронных операций и обмениваться с главным потоком данными посредством IPC, но это «на общих основаниях». Само gtk в распараллеливании задачи тебе не помощник.

Если интересно, можешь посмотреть, как реализовано API для асинхронной работы с файлами в stuurman/pcmanfm: https://github.com/sde-gui/libsmfm-core/tree/master/src/job

Deleted
()
Ответ на: комментарий от shdown

Как библиотека называется-то? Вроде lua51/lua-5.1/lua51 должна.

Примерно так всё выглядит:

usr/bin/lua
usr/bin/luac
usr/include/lauxlib.h
usr/include/lua.h
usr/include/lua.hpp
usr/include/luaconf.h
usr/include/lualib.h
usr/lib/liblua.a
usr/lib/liblua.so.5.1.5
usr/lib/pkgconfig/lua.pc

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

В том, что у меня есть SCADA система, и я могу написать плагин для мониторинга на баше/си/крестах/sml/удобном языке и дергать процесс по определенным событиям.

Напиши программу, которая выводит что-то в stdout, и используй плагин pipe, не?

В твоем случае я должен писать на луа? На сях?

Объясни нормально, что тебе нужно мониторить и по каким событиям обновлять.

А если оно работает через дбус, мне дбус интерфейс в си/луа городить?

Для dbus пока плагина нет, можешь issue открыть. Можешь сам написать, на сишке, да.

А на Lua в любом случае придётся виджет писать, но там обычно не много, см. https://github.com/shdown/luastatus/tree/master/contrib/widget-examples

Костыльно запускать процесс для обработки события? В юниксе это традиция, так-то: пайпы, форкающиеся сервера, ipc.

Это костыли, и CGI уже давно не в моде, т.к. тормоза.

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

Это костыли, и CGI уже давно не в моде, т.к. тормоза.

Ну, тут прямая дорога на винду, там и потоки легкие, и городить монолитные процессы принято, и писать все на одном (единственно верном) языке.

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

А примеры виджетов для dwm есть? Ни один не пашет, даже xkb.lua:

luastatus -b dwm -l trace -e ./xkb.lua
luastatus: (barlib) error: expected string or nil, found table

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

Ну, тут прямая дорога на винду, там и потоки легкие, и городить монолитные процессы принято, и писать все на одном (единственно верном) языке.

Будто что-то плохое. Избавляйтесь уже от этого сектанства. Если решение объективно лучше, почему бы не использовать его?

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