In summary, the gaminrc file worked for me, whereas copying the /usr/share/doc/openbox directory to /usr/share did not. But, why did it take so long to repopulate the Applications pipe menu? Probably because I'm running folding@home on that box, and folding@home uses all the CPU cycles not used by other programs. CPU usage is usually between 99 and 100% while running folding@home.
So far, all I need to do is to look at PCManFM>Applications and highlight a change for any change to take effect.
It immediately affects the menu then. Why ? I don't know. Just the way it is. Qualifies for a known
issue I guess. Perhaps the upgrade will include a program loop to set those changes thru immediately, rather than
an eternal poll as is suggested, as an additional program step. This menu is simple enough to be able to do so, I agree.
I think this flowchart is valid if I'm thinking as you are. A one time all around menu refresh, if you will. Just a few
seconds. A sync procedure was mentioned for the upgrade but the full details I don't have. But, a quick refresh
sounds the best overall. My program logic is good but my syntax is terrible so I stay a casual user/tester anyway.
This wonderful menu needs to be pinpointed till it's foolproof no doubt. My only surprise is categories
that don't exist in the static or default menu. So I use obmenu from Synaptic to create some new
menu categories then. I don't mind that.
Hey, this is PCL Openbox 2011, technologically ahead by at least a year of other Openbox distros
in the public domain, no names mentioned.