Thomas Funk <t.funk...@googlemail.com> writes: > 2012/7/17 Dan Espen <des...@verizon.net> wrote: >> Thomas Adam <tho...@fvwm.org> writes: >> >>> On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote: >>>> Thomas Adam <tho...@fvwm.org> writes: >>>> >>>> > On Mon, Jul 16, 2012 at 11:35:20PM +0200, Thomas Funk wrote: >>>> >> Regenerate Menu(s) >>>> > >>>> > Why can this not be an on-disk cache or something instead of requiring >>>> > the >>>> > user to care to regenerate the menus? >>>> >>>> The purpose of Regenerate Menus is to get a new menu after you've >>>> installed a new package. A cache would only make the problem worse. >>> >>> Actually, no. Effectively this is what Debian does with its menuing system >>> and it works just fine. I see no reason why we need an explicit >>> regeneration of these menus. >> >> I'm not following. >> >> If I install a new package, say Evolution, it won't be in the Fvwm >> menus. Not until the menu is regenerated. >> >> How is a user supposed to get a new menu with Evolution in it? > I've looked a little around and the easiest way is to scan the > $XDG_DATA_HOME ($HOME/.local/share) and $XDG_DATA_DIRS (/usr/local/share/, > /usr/share/) periodically if .desktop files are added/removed there.
Polling for changes? Nope, I'd rather require specific user action. > For that an own module for menu creation/changing/updating will be > beneficial ;-). Due to the fact that I am working on that stuff I would > start with such a module. But could take a little while ;-) ... > > In the meantime it would be fine if anybody who's interested in helping > would test fvwm-menu-desktop and report bugs here on the list. > > Dan, I will send you a small bugfix patch for the actual CVS version. The > fixes are in the last patch included but as this is a proof of concept > would be better to seperate them. Okay. As you've seen I'm a bit slow to look at these things. I haven't looked at your latest work yet. I will get to it though. -- Dan Espen
