Simon Oosthoek posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 11 Oct 2003 22:48:08 +0200:
> On Sat, Oct 11, 2003 at 05:58:02AM -0700, Duncan wrote: >> Mandrake's menu system is based on the Debian menu package. KDE packages >> are adapted to use the Debian global menu system, which then recreates the >> KDE menu, including non-KDE Mandrake applications in it that wouldn't be >> included in the official "non-distrib-ified" KDE product. > > Do you know a good pointer to documentation for this intertwined feature? > Menu's have been a mystery to me for quite a while, I'd like to know how it > actually works... /usr/share/doc/menu-X (currently X=2.1.5) Basically, the idea is to create a global system menuing system that can be adapted (thru the use of scripts for each window manager or environment) to all the various windowing systems, such that a menu entry must be added only once for each new installed item, and each window manager will automatically pick it up and add it to its own menu. The system allows for wm/environment specific attributes for each one, such as the various custom stuff entered in each KDE *.desktop file, and for entries specific entries only to be used with one wm/environment. KDE itself, as mentioned, uses *.desktop entries in a subdir system very similar to the MSWormOS start menu idea, where each menu entry is a separate file in the file system. Unlike the MSWormOS start menu, however, the menu entries track file type associations, the app that launches when you left click (or doubleclick depending on your KDE options), and additional apps available to "open with". This is what managing the file type in KDE changes -- the priority number assigned to this *.desktop entry for opening that file type. and the various entries that are associated with it that can open it. Unfortunately, changing those attributes doesn't make the same changes in the Gnome menu (well, that's good in some ways, as you might not WANT it to open with say Konqueror when in Gnome, but ..) and in any case, as soon as you upgrade, which happens pretty frequently when one is running Cooker, the changes are often erased. Debian came up with the menu package, which Mandrake adopted, which makes global changes possible. Edit the menu once, globally, and changes are applied to all window managers as specified in the *.mnu files you (or whatever graphical front end such as menudrake you are using) create. As I mentioned, however, using menudrake has its drawbacks. One of them is that most of the custom KDE attributes, for instance, show up in a single **VERY** long at times string, and the window for editing these attributes in menudrake is **VERY** small by comparison, only a few characters, so you get the "keyhole" effect. Another problem with menudrake is that there's no easy way to duplicate entries, if you want a menu entry in two different locations or want to duplicate one in ordered to change it a bit for a second entry. Yet a third problem is that the icon choice in menudrake has no accompanying text box for direct path entry -- one cannot see where the icons are nor enter their own path, all one can do is choose from a limited system set already there. The final problem is that *.mnu files can consist of a single menu entry per file, or be grouped, and menudrake groups **ALL** its changes into a *SINGLE* override file, easy to backup if one knows where it is, but not so easy to hand edit, and not very robust. (Most *.mnu files are only a single menu entry, far easier to maintain and change by hand, and if one gets corrupted, the rest remain fine. Using the documentation found above, however, and looking at a number of existing *.mnu files, I was able to figure out the format, and now make all my changes by hand. A general list of most possible entries for the distrib is stored under /usr/lib/menu/. This includes entries for apps that aren't installed, as well as installed apps, with each *.mnu file including both a package that must be installed to activate it, and an environment (general X, KDE only, Gnome only, etc) under which it is to be viewable, the latter corresponding to the entries in menudrake that are visible only under one environment, not all of them. Thus, installing the package automatically activates the *.mnu file and adds the menu entry for it, while uninstalling it removes it, deactivating the *.mnu file. This is accomplished thru a step in the appropriate rpm script that invokes update-menus, a command that can be invoked by hand, as well. Sysadmins may create override entries to add or change the defaults and put them in /etc/menu/, which is in effect what menudrake does when you customize the menu. Again, the problem with menudrake is that it puts all its customizations in a single hard-to-maintain-by-hand file, while it's generally easier at least when doing it by hand, to simply copy the appropriate file over from /usr/lib/menu, and then modify it as necessary to make the customizations you desire (which can include simply placing a an empty file of the appropriate name in the override location, killing the default entry. Of course, editing the text files by hand means all the disadvantages of menudrake listed above no longer apply. I can copy entries at will, work directly with the icon paths, and use a full screen editor to change those long attributes (which can then be spread over several lines using the \ escape character b4 the newline). As well, if I don't like the menu layout, I can use sed or similar to change every occurrence of one path to another, putting all amusements, games, and toys, under the same "games" menu folder, for instance. Of course, users can make their own changes using either menudrake or by hand, with these changes to the wm menus themselves being stored in ~. The system doesn't store *.mnu entries for the user themselves, as I recall. (I may be wrong on that, tho, as being the only user here, I always modify the system menu, keeping root and my various alterego users all in sync.) .. BTW, this is what I was talking about in the rpmdrake/installer thread. All the *.mnu files even for stuff not yet installed is already (for the most part) kept in /usr/lib/menu, just waiting to be activated. Most of the icons used are already in their various locations as well, at least if one has X and KDE or Gnome installed. Thus, using a menu based installer with all entries listed wouldn't be a big thing at all. As I proposed it, yes, there'd be another set of *.mnu files, with identical icon listings, but tracking installed status of the menu items they represented. However, given the current situation with a *.mnu file already present for most items, installed or not, and the fact that we ARE talking about text files of relatively modest size, additional space usage would be minimal. Including the new installer, we're only talking the equivalent of a single moderate size package, nothing more. Considering the lengths it would go toward improving intuitive installation management, and the fact that it uses already well understood and currently included methods and technologies, meaning implementation should be simple and bugs minimized, it seems to me it would be well worth implementing that way. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
