Well I did a little research into this and I have more information (though still no answer). In KDE 3.2 the menu standards went to the freedesktop standards. While it's nice to have standards, this went from a system where it was one menu (stored in your local dir that was generated from a global) to a multi-menu system. What I've gathered so far is that this menu structure uses 3 file types to define the menu split us thusly:
(according to the KDE site, for KDE):
.menu is stored in 2 global and 1 local location
.desktop is stored in 3 global and 1 local location
.directoy is stored in 3 global and 1 local location
This unfortunately means that the system is *expecting* local AND global files and is reading from a variety of locations. This means that as far as I know there is no "linking" trick I can do. However, what is happening on my (and apparently other) people's systems is that duplicate names are going into the menus (some sort of global vs. local thing) and we're losing menu entries, directories, etc. As I mentioned before, I basically stopped using the menu as much as possible until this gets resolved. However, given this was a change in 3.2 and it's still a problem in 3.5x there must be a workaround by now!
The only other thing I can possibly do is edit all (let's count 'em) 11 locations by hand (and there's a lot of files in each location). This is a lot of hassle just to get my start menu (kmenu) working!
Does anyone have a better solution for this? Are there any utilities around that I can replace KMenuEdit with? Is there a possible directory linking solution?
The only thing that I can think of off the top of my head is that since I don't use gnome I can move all the global locations for each file type into a single global location. Then I could *attempt* to link my local dirs to the global dir I've specified. Though honestly I don't know what would happen if I did that. (And that's why I always make backups first.
)