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

List:       kde-devel
Subject:    Re: RFC: new KPanel application menu
From:       iglio () fub ! it (Pietro Iglio)
Date:       1999-07-23 9:37:14
[Download RAW message or body]

At 01.00 23/07/99 PDT, David Beattie wrote:
> Here's how I would implement it:

What you suggest is a possible way to implement that idea. I'm currently
implementing it in another way (actually Waldo Bastian suggested me that
in a private mail exchange):

desktop file aren't used to represent the menu structure any more, but
only info about an installed application (Name, Icon, etc.)
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
...

A menurc file looks like:

MenuItems=Konsole,Kvt
HiddenItems=Trashcan
AddedItems=Kvt

where:

- MenuItems are the actual menu entries at that level (merged with the above
   levels);
- AddedItems are the items added at that level;
- HiddenItems are the items of the above levels hidden at that level;

(when I say "level" I refer to the configuration level, not to the menu
structure);

Using AddedItems and HiddenItems I can merge the levels from the most
general to the local level into a unified menu.
One advantage is that you can move an item from a menu to another just
adding it to HiddenItems in the "from menu" and adding it to the
MenuItems and AddedItems in the "to menu". You also get the sort order
for free.

>(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.
> ....

I like this idea.

>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'll think about that.

>(Here's interesting concept number four:?)
>
>Someone mentioned the problems associated with left-click-drag editing of
>hierarchical menuing systems.  
>...
>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).

This sound like a good idea to me. It's not a "real" drag'n'drop, but I
don't think that this will confuse users and solves the problem of
"accidental drags".

-- Pietro Iglio

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