[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: RFC: new KPanel application menu
From:       David Beattie <dbeattie () usa ! net>
Date:       1999-07-23 1:00:09
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]