That is very weird. I can't think why that would happen. If you replace /usr/bin/openbox-menu with this new version, and then restart Openbox, does that work? Because that's the main thing (you may want to back up the original /usr/bin/openbox-menu, though).Strange, if I do that exactly like you say (with the "&" to put it in the background), it just seemingly does not do anything (I still have the old menu in /tmp/obcache). If I omit the ampersand however (or type "fg" after starting it with the ampersand), it works perfectly: /tmp/obcache/progmenu is now only 2224 bytes and it created 24 submenu files named 1 to 24.
Updates are noticed by menu-cache (/usr/libexec/menu-cached), which caches the results of parsing through /usr/share/applications/ into a file at /tmp/obcache/menus/[biglongfilename].Question: how does the menu get updated when new PNDs are detected? I'm assuming that you somehow send a signal to make the openbox-menu daemon re-create the menus? In that case, is it really necessary to use a daemon - can't you just call openbox-menu to create the menu once and then quit? (this would save a tiny bit of memory, probably not worth it but still)
openbox-menu is a front-end to menu-cache - it starts it up, and gives it a callback function to call when changes happen. Since its openbox-menu that drives menu-cache, rather than the other way around, there needs to be a way for openbox-menu to start up. At the minute, it's started up once, and continues running as a daemon. Previously, it was started at login, and then quit, then started every time the "Programs" menu was selected (the menu displayed was openbox-menu's STDOUT). I had thought that this was the reason for the menu lag. Even though this assumption wasn't entirely correct, I think piping the result of "cat /tmp/obcache/progmenu" is always going to be quicker than piping the result of "openbox-menu /etc/xdg/menus/op-pnd.menu".
So, currently, there's 3 daemons running: pndnotifyd monitors for new PNDs and creates entries in /usr/share/applications/, menu-cache monitors /usr/share/applications/ and caches the result, and openbox-menu transforms that result into a menu. I'll look into the possibility of changing pndnotify or menu-cache to see if they can start openbox-menu when required (3 daemons seems a bit much, but there may not be enough benefit from changing it).
It's mostly static, yes. On my machine, it's totally static (sometimes I even kill pndnotifyd). But I'm trying to cater for everyone, and I assume there's people who yank SD cards in an out, and need very dynamic menu content.Also, do you really need pipe menus? The content is mostly static, so can't you use regular file menus and signal openbox to reconfigure whenever it happens to change?
The alternative to pipe-menus would be to put everything into $HOME/Applications/Settings/openbox/menu.xml. One side-effect of this, is that it would make it less readable, and so make it harder for people who want to edit the file to rearrange the root menu. Also, I'd have to parse that file, amend the contents, and output the result again, which could be an error-prone process, especially with me doing the programming. Additionally, I'm not sure how safe calling openbox --reconfigure is: I don't know how it affects running applications, and I don't think it's the standard / recommended way to deal with dynamic content.
Last edited by a moderator: