On Tue 09 Sep 2003 15:09, Buchan Milne posted as excerpted below: > This will not work until all desktops use one menu/mime-type system (who > the idiots were who decided to implement one per desktop is something I > would like to find out ...). Your associations will be reset every time > you run update-menus (which happens when you log in, and should happen > after you install a new package). You may be able to put entries in with > the menudrake, I haven't tried.
<rant> I finally took to creating my own alternative menu file override entries in /etc/menu, copying entries from the mandrake-defaults in /usr/lib/menu to /etc/menu then changing them as necessary. I got tired of the limitations of menudrake such as tiny attrib edit dialogs that show perhaps 15 chars (non-resizable windows) when attribs like kde_opt are commonly hundreds of characters long. I have three monitors @ 1280x1024 each precisely to avoid the "keyhole effect" of small viewports, and that's precisely what the menudrake attrib edit dialog gives me. As well, there's no way in menudrake to duplicate entries, except for creating a new one and painstakingly copying the attribs one by one. On the icons, since it doesn't list the path to the icon, just shows it, it's difficult and sometimes impossible to create a new entry accurately anyway, because you can't find the proper icons! Finally, it's entirely to easy to wipe out a whole slew of changes by saving the wrong config when switching between the user settings and the default settings, in part because menudrake stores all changes in a single file instead of one file for each menu entry, as are the original files. (Yes, I should really file bug reports on all this, but I'm going to wait until post 9.2 since it's in freeze.) All these problems are resolved by doing it the old fashioned way -- copying the config files as necessary and editing them in your favorite text editor, then running update-menus manually. The documentation is where one would expect under /usr/share/doc/menu-<version>, or one can just look at existing entries and figure out what is going on. This sort of customization allows for several improvements. One, I can actually get file associations to STICK, system-wide, and not get over-written each time! Two, I can put my own command line options and other customized attributes in, and have them STICK! Three, the menu items stick around better, causing less problems with khotkeys losing its settings because the menu item disappeared at the last update due to some package change, as invoking a hotkey on a non-existent menuitem causes khotkeys to erase that entry from the hotkey config, so even when I got the entry back, I was having to manually configure the hotkey for it again. With properly modified /etc/menu/ menu file entries, the menu entry remains even if the default package it formerly depended on split out from under it or some such, and the default entry is no longer there. </rant> -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
