I have several comments and concerns about the new implementation. First, I think the idea of separating the definition of applications from definition of the menu listing those applications for users is wonderful! This allows applications to be defined and not included on the menu. (This may be possible with KDE 1.1, but if so, it is not well-documented, so I don't know how to do it. I have a "Save As..." application defined that accepts all file types and uses "kfmclient copy %u %u" to implement a (kludgy) save-as functionality, and I have to live with it being on the menu, apparantly.) I hope, then, that a mechanism for making small incremental changes to a system-defined application (or at worst, simply overriding it by a re-definition at a more local level) is in place, so that customization (such as adding command-line parameters or changing the name of the application) is possible. Changing the name of the application is particularly important, because annoying for-profit vendors (such as may of course start to write apps for KDE, once it becomes a stable operating environment) like to splash their company name around, putting in menu items like "Company A's Application Name v 2.4", which I might wish to change to "App" for simplicity, yet the sysadmin might not have cared. Or the application name could be changed to something more meaningful to someone who cannot always remember what "KLyX" does, but only on his/her local menu. >A menurc file looks like: > > MenuItems=Konsole,Kvt > HiddenItems=Trashcan > AddedItems=Kvt Storing each sub-menu definition in one file per level of the configuration hierarchy instead of in the filesystem has the advantage of decreased start-up time, since far fewer inodes must be accessed. This is in most ways a good thing. But it does have the disadvantage of practically requiring a helper application: >kmenueditor --add Konsole.desktop MyUtils/Shell/ >kmenueditor --remove Konsole.desktop MyUtils/Shell/ >kmenueditor --move Konsole.desktop MyUtils/Shell/ MyUtils/ to allow for script-based automatic menu-item creation. I suggest moving this functionality into kfmclient, where I believe it belongs, and continuing with plans to do away with kmenueditor all together. I also assume, then, that there will be a prohibition (well enforced, I hope) against a .desktop file having a comma in its filename? If not, then perhaps these will have to be \-escaped or something similar, in the menu file format maintenance and reading routines. I'm wondering...it seems from this example that application .desktop files in the newly-being-developed KDE editions are now in a flat namespace? Is this true? (that could be a good thing, or a bad thing, I'm not sure. But I know there is at least one dialog in KDE 1.1, the open-with dialog, that would look very different with a flat application namespace.) >A menurc file looks like: > > MenuItems=Konsole,Kvt > HiddenItems=Trashcan > AddedItems=Kvt It seems to me to be redundant for the menurc files to have the "MenuItems" configuration entry, since its contents can be entirely predicted from contents of the AddedItems and the HiddenItems at all levels. If all levels of the configuration hierarchy are being monitored for changes, is it not just as efficient to simply re-read the changed menurc files when they change, and rebuild the in-memory merged menu-item list, and then not bother with re-writing the local configuration file to hold the cached menu description. True, there is greater efficiency in only having to read the contents of one file (while stat'ing all the others) in a typical start-up, but I get the feeling the merge algorithm must be quite complicated to be able to handle all possibilities, and could get buggy very easily, and I would think, with modern filesystems, that reading a small file would not be significantly more expensive than stat'ing it. And with the idea I had about the user being able to show hidden items by depressing the shift key, the contents of all the files would have to be read anyway in that case (unless there were a fourth line in the configuration file caching that case, too). >The menu structure is stored in menurc files: >share/apps/kpanel/menu/menurc >share/apps/kpanel/menu/Utilities/menurc >share/apps/kpanel/menu/System/menurc >... I hope there is one extra configuration item in the menurc files or somewhere, "Name=" so that menus can have arbitrary/foreign characters in their names (and '/'s and '.'s and other interesting characters. It is always very annoying me in Microsoft's Win98 to not be able to give a menu a name with a '/' in it because it's tied to the filesystem's name limitations. But now that I think about it, foreign characters are more important even than that). Unless there are other files per directory besides "menurc", perhaps we could save some inodes and directory reads by making it: share/apps/kpanel/menu/.menurc share/apps/kpanel/menu/Utilities.menurc share/apps/kpanel/menu/System.menurc Of course, this would require stuff like share/apps/kpanel/menu/Utilities.Editing.menurc to have an "Editing" submenu of "Utilities", which brings up a much more interesting issue: Users should be allowed to move or rename system-defined menus, just as they can move or rename applications on those menus. For this reason, I propose making a menu just a special kind of application...perhaps it would only be defined in the share/apps/kpanel tree, and not visible to the system application database, but if as far as the kpanel was concerned, a menu was a special case of an application, which contained instead of an execution string, a list of AddedItems and a list of HiddenItems in addition to a Name...then menus could be moved around at will, by placing them in the AddedItems and the HiddenItems fields of other menus. Of course there would be one root menu, the .menurc file, which would contain as part of its AddedItems the other .menurc files, for example: file .menurc ------------ Name=Where do you want to go tomorrow? AddedItems=Utilities.menurc,System.menurc,Trashcan HiddenItems=Editors.menurc file Utilities.menurc --------------------- Name=Utilities AddedItems=Kpm,Konsole,Editors.menurc,Utilities.Graphical.menurc file Editors.menurc ----------------------------- Name=Editing AddedItems=KEdit I know this solution is not perfect (the issue of reconciling the application and menu namespaces I have not addressed, but I don't think that would be hard), but you can see how easy it would be to move and rename submenus... (I have shown an example of moving...renaming would be by changing the Name entry at a more local level than the Editors.menurc file was originally defined at.) I would suggest that menus introduced at a lower level still have the parent menu name prefixed to them (like my Utilities.Graphical example, so that namespace conflicts will not be easily introduced by adding a submenu, and it would typically be obvious from looking at the filename where a menu is located in the menu tree, although the file space would be flat. Finally, here's something to think about: >The rc file concept promises to >a) be faster (when parsing) >b) save space >c) offer more flexibility (sorting order etc.) without touching the > format of .desktop files each time we need a new feature. This last point...flexibility regarding sorting order, is indeed interesting. We could introduce the feature of allowing the user to move items and maintain a non-sorted ordering to the menu if they wish, a la Win 98 (although I don't think Win 98 implemented it perfectly). This would, of course, require some creativeness when dealing with merging multiple levels of hierarchy where higher levels are out of sort order...and I don't have a solution for that yet (although I have a few ideas I can throw around if anyone thinks such a feature is a good idea). That's all for now, again, regards to all of you, David Beattie ____________________________________________________________________ Get free e-mail and a permanent address at http://www.netaddress.com/?N=1