From kde-devel Fri Jul 23 01:00:09 1999 From: David Beattie Date: Fri, 23 Jul 1999 01:00:09 +0000 To: kde-devel Subject: Re: RFC: new KPanel application menu X-MARC-Message: https://marc.info/?l=kde-devel&m=93271700918715 I'm new to this forum, but I've been thinking about this exact KPanel application menu issue for months, and I think I have some ideas to contribute. Sorry I'm a bit late in joining this particular discussion...I wasn't subscribed to kde-devel before now, and had quite a little trouble getting myself subscribed--the mail transfer agent on the kde list server was rejecting me because the corporation I work for is using UUCP so that the IP address wasn't fully reversible to the source machine (or, at least that's my best guess)...very annoying, especially considering it took several days for the error message to come back, and the error message is too cryptic for me to know completely what is the problem. But anyway, I hope it likes a usa.net free account better. The idea of merging the application menus at all levels of a hierarchy and allowing customizing changes to be made at any level is an excellent one. Here's how I would implement it: Modification of a menu item would be done by storing the differences in the configuration data. I would not store unmodified configuration data at the more local level. Deletion of a menu item would be done, as several have suggested, by an entry in the local menu item which disables it (for example, "Deleted=yes"). (Here is the interesting part:) Moving of a menu item would be done by placing two configuration entries in the local menu file (for example, "Moved from=Utilities/KEditor.kdelnk" and "Moved to=Utils/KEdit.kdelnk"). Also, just as important, I would place a hard link to that local menu file in *both* places, so the file containing those above two entries would be in both locateLocal()/Utilities/KEditor.kdelnk and locateLocal()/Utils/KEdit.kdelnk. When reading the menu from disk, KPanel would compare the file it is reading to the "Moved from" and the "Moved to" locations. If equal to the "Moved from" location, the menu item would be marked as one not to display. If equal to the "Moved to" location, though, the missing (because redundant, specified further up the hierarchy) data would be read from the "Moved from" location further up the hierarchy. [Thus my "Moved from" location is the same concept as the "Origin" entry proposed earlier.] This duplication of disk position for the menu entry (it could be a soft link instead of a hard link, I suppose) would allow KPanel to build any arbitrary submenu without reading the entire menu, and so would cut down on the complexity of the algorithm since it eliminates the need for inversion of data structures. Actually, for efficiency, I would probably combine the concept of deletion and moving, and use a single configuration entry "Removed from" to express that a menu item is not to be displayed in a particular location, instead of separately named "Deleted" and "Moved from" entries for the separate purposes which both acheive the same result. And the recording of the location a menu item is being deleted from into its configuration file can't hurt (could be useful in some way; if for nothing but consistancy checking). (Here's interesting concept number two!:) I would make it so deleted or moved menu items could be displayed in the menu in their original location by pressing the shift key (or another modifier key on the keyboard), which would temporarily cause KPanel to ignore the "Removed from" modifier on menu items. This is important for two reasons: 1) a user should be able to re-enable a menu item he or she has deleted. If it is hidden from the menu, the use of something like KMenuEdit or direct text editing of the configuration file would be required to get it back. This would be unacceptable in the case that removing the item was an accident, and at best not user friendly if the item had been removed on purpose. But if hidden menu items can be shown by depressing the shift key, then, a context menu can be brought up on the mistakenly "deleted" menu item, and it can be restored to view. 2) help desk personnel and sysadmins would like to have a consistant, unchangeable menu structure, while users would like to be able to reorganize their menu at will and delete seemingly useless pieces of software. With the 'shift-to-restore' functonality, a sysadmin or help desk person could instruct the user to press shift-KPanelmenu, System, Fontmanager without having to worry about the user having removed it as clutter from his menu. Of course, a knowledgable user could deliberately use this functionality to give himself an uncluttered menu without losing the ability to run obscure applications once in a while, and in fact, I would expect that most KDE users should become familiar with the shift-to-show-hidden technique if they ever try to edit their menus, so many may use it deliberately as a "feature". A picky point about the idea of "publish"ing a menu item... It seems to me that it is not necessary to introduce such a new concept into the user interface...rather, I would suggest simply adding a dialog box onto the "OK" and "Apply" buttons on the property editor for a menu item (and the same dialog box could pop up when moving or deleting a menu item) that would pop up and ask where the changes should be applied to, whenever a user who is making a change has write access to multiple levels of the menu hierarchy. (Of course, for a normal user who only has write access to a single level of the menu hierarchy, no such dialog would appear). I would also propose a "Restore Defaults" button on the property editor for a menu item (and of course something similar on the context menu for a moved menu item) which would allow elimination of the user customizations for a menu item. And as usual, this concept has precident in other KDE (and other operating systems') dialog boxes. (Here's interesting concept number four:?) Someone mentioned the problems associated with left-click-drag editing of hierarchical menuing systems. (In fact, my brother once completely destroyed a Microsoft Windows machine, by accidentally dragging the C:\Windows\Profiles directory (which contains the Windows registry, when "profiles" are enabled) to be a subdirectory of C:\Windows\Inf. how's that for an operating system! I went into Linux and located the folder and moved it back.) I propose the following solution, which could be of course compared for usability with the minimum-threshold-of-movement idea proposed by a couple of other people. Put the "move" operation on the right-mouse-button context menu for a menu item! Clicking on such a menu item would immediately initiate the move, which would be exactly like a normal drag and drop except that the user may not be actually holding down the button throughout the entire drag operation, and would rather have to re-depress a mouse button before the release of a mouse button would trigger the end of the drag (as normal) or the Esc key cancels it (as normal). That's all that I can remember that I had to say about this discussion from last week, that's appropriate for this message...if this goes through, I have a couple other minor, marginally related issues/questions to raise in a second message. Regards, and with much respect for all you guys' fine work, David Beattie ____________________________________________________________________ Get free e-mail and a permanent address at http://www.netaddress.com/?N=1