openbox-menu -f jwm

[geekless]

Если посмотреть на проблему свежим взглядом...

то заметим, что потребление памяти при работе с menu-cache+openbox-menu по сравнению с обычным меню+fixmenus в JWM возрастает, напр., при загрузке системы до раб.стола и запуска только htop потребление памяти по данным того же htop у меня увеличилось с 68...72 Мб до 100...110 Мб, но при таком раскладе тогда уж проще поставить Openbox+*panel (ИМХО).

Всё это более, чем странно. Я проверил в виртуалке, запуск openbox-menu -p добавляет к потреблению памяти 3 мегабайта.

[geekless]

Скомпилил. Без улучшений : http://forum.puppyrus.org/index.php/topic,14731.msg81316.html#msg81316  

Только что поставил menu-cache-0.4.1-1-i686.pkg.tar.xz . Перекомпилил под него openbox-menu
Теперь
touch /usr/share/desktop-directories/fake-item.directory  и pacman - установка передергивают меню
Подключение модуля НЕ передергивает. Не проблема - вставить touch в подключалку
Получается дело в menu-cache
menu-cache-0.4. отрабатывает медленнее. Придется sleep 2 && jwm -reload

Я не подтверждаю различий, с моими патчами всё работает правильно: изменение любого файла в /usr/share/applications приводит к обновлению меню.

[sfs]

потребление памяти при работе с menu-cache+openbox-menu по сравнению с обычным меню+fixmenus в JWM возрастает

Насколько я понял - не зависимо от панели все идет через menu-cache (не уверен про xfce и выше). Исключение - jwm icewm. Где меню формируется костылями (пупи) или пишется 1 раз руками  (в остальных jwm дистрах, которых не много)
+ куча разношерстных индикаторов в трее.
Получается - если заморачиваться потреблением памяти - jwm + fixmenus + conky. Про идею bash-демона-обновлялки меню никто не отписался...
Не заморачиваться - смотреть в сторону других панелей. Наиболее интересной кажется waterline - плагин "кнопка" может заменить зоопарк в трее. Потребление памяти надо смотреть...

Я не подтверждаю различий, с моими патчами всё работает правильно: изменение любого файла в /usr/share/applications приводит к обновлению меню.

Вы тестируете под PRA? Компилили сами? Выложите бинарники...
RoDoN - рассуди нас (перепроверь)

[RoDoN]

изменение любого файла в /usr/share/applications приводит к обновлению меню.

Скомпилил в PRA варианты menu-cache и openbox-menu из git по состоянию на сегодня 00:15, работает следующим образом:
1. Подключаю .pfs - меню не меняется, меняется только после рестарта иксов. выполнения п.3
2. Установка через pacman - аналогично п.1
3. Копирую напр., /usr/share/applications/mc.desktop в /usr/share/applications/mc2.desktop, тогда появился еще один пункт с mc, удаляю /usr/share/applications/mc2.desktop - лишний пункт mc исчезает.

З.Ы. Похоже не очень внимательно читал, но оказывается выполнение:

Код

sudo touch /usr/share/desktop-directories/fake-item.directory

передергивает меню в п.1, т.е. команду надо в скрипт монтирования добавить.

Вы тестируете под PRA? Выложите бинарники...

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

Про идею bash-демона-обновлялки меню никто не отписался...

А кто должен отписаться? Ведь в теме кроме нас троих никто ничего не пишет, толи нет интереса, толи даже не знаю, наверно не заморачиваются... От себя могу сказать, что сам написать не смогу, а протестировать всегда пожалуйста и если по скорости работы и потреблению ресурсов устроит, то я только "ЗА"

[RoDoN]

Собрал то, что накомпилил в zzzz-rootcopy-r10.pfs (сделал на основе zzzz-rootcopy-s09.pfs), перед подключением удалить zzzz-rootcopy-s09.pfs b zzzz-rootcopy-s09a.pfs, если они есть.
Создал /usr/local/bin/jwm-obmenu с таким содержимым:

Код

#!/bin/sh
`which sudo` touch /usr/share/desktop-directories/fake-item.directory
openbox-menu -f jwm -I 16 -p -o jwm-app-menu -R 'jwm -reload'

в связи с этим переделал /home/live/.jwmrc так:

Код

<StartupCommand>jwm-obmenu</StartupCommand>
<RootMenu label="Меню" labeled="false" onroot="3">
      <Include>$HOME/.cache/jwm-app-menu</Include>
<Separator/>

и еще в файле /usr/local/bin/jwm_menu_refresh изменил 7-ю строчку так:

Код

[ "`which openbox-menu`" ] && jwm-obmenu & exit

Теперь вроде бы меню обновляется и при подключении .pfs и при установке через pacman.

[sfs]

При старте с zzzz-rootcopy-r10.pfs в процессах по 2 menu-cached и openbox-menu.
Насколько я понял openbox-menu как раз и вызывает  menu-cached
Здесь все плохо:

Код

[ "`which openbox-menu`" ] && jwm-obmenu & exit

Получается что демон openbox-menu запускается много раз
Наверное && exit или && (jwm-obmenu &) && exit
Если демон openbox-men сам все не делает - значит надо запускать без -p
menu-cached - нужен только openbox-menu (в PRA) и нормально у меня заработал только так:

Код

`which sudo` touch /usr/share/desktop-directories/fake-item.directory
rm /home/`sfsusr`/.cache/menus/*
openbox-menu -f jwm -I 16  -o jwm-app-menu && `which sudo` killall menu-cached

menu-cached - без костылей все равно не работает. Поэтому убиваю в конце
В таком варианте все работает - но костыльнее я ничего не видел
Если удастся починить menu-cache - тогда ок, но тяжеловато для jwm
Научился править menu (в аттаче) Переделал

Поэтому лучше допиливать п.4

[RoDoN]

то заметим, что потребление памяти при работе с menu-cache+openbox-menu по сравнению с обычным меню+fixmenus в JWM возрастает, напр., при загрузке системы до раб.стола и запуска только htop потребление памяти по данным того же htop у меня увеличилось с 68...72 Мб до 100...110 Мб

Всё это более, чем странно. Я проверил в виртуалке, запуск openbox-menu -p добавляет к потреблению памяти 3 мегабайта.

Перепроверил еще раз разные варианты загрузки, оказалось я ошибся в том сообщении. Вы правы, запуск openbox-menu действительно добавляет примерно 3 метра, а потребление 68...72 Мб было в PR-13.07, а в PRA меньше 92 Мб добиться не смог и то только при отключении записи логов. Так что использование menu-cache+openbox-menu не такое уж и тяжелое для JWM.

[sfs]

в PRA меньше 92 Мб добиться не смог

Кстати в archbang памяти есть чуть ли не меньше, не смотря на то, что NM и т.п. запущено
Надо будет поразбираться с этим. Возможно на frugal дела что-то уходит...

...что-то geekless пропал с 21.09... Кто в теме - на LOR он появляется? Вроде писал гриппом болеет... 

[Pro]

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

[sfs]

Да, в этой теме без него делать нечего... 
ilyuk заходит, но молчит 
Больше у нас программеров не знаю...

[sfs]

Доделал вариант openbox-menu -f jwm. Заработало за счет http://forum.puppyrus.org/index.php/topic,15211.msg85760.html#msg85760
menu-cach из арч репы. Переделанный geekless тоже работает
Это более правильный метод, который открывает дорогу к lxpanel openbox и т.п.
Все работает , но медленнее. Т.е. пункт загруженного модуля появляется чуть медленнее, чем при старом варианте
Модуль menu-cach - положить в /modules
Модуль zzzz - /optional

[sfs]

На мурге заинтересовались
До кучи конвертер jwm-меню в gtkdialog gui - т.е. можно использовать там, где нет никакого меню

[paulus]

пункт загруженного модуля появляется чуть медленнее, чем при старом варианте

Чем плох старый вариант?

[sfs]

Не скомпилить под 64бит. Пришлось в ПРА64 делать через sh (скорость не мерил).
Кстати - если лезть в jwm 2.3 старый может перестать работать. Поправить проблемно (Си)

[paulus]

Пришлось в ПРА64 делать через sh (скорость не мерил).
Кстати - если лезть в jwm 2.3 старый может перестать работать.

Нормально работает через sh с jwm 2.3, только менюхи аглицкие у меня и во всплывающей панели (верхней) не все кнопки выключения/перезагрузки работают.