[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-26 8:23:05
[Download RAW message or body]

At 18.59 25/07/99 PDT, David Beattie <dbeattie@usa.net> wrote:
>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.

That's not a problem. I guess that you can already use escaped commas
(it's a kconfig job).

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

Application .desktop files are now in a flat namespace. You can install
all of them under share/applnk or under any subdir (as in the current
implementation). The directory tree (Utilities/, Internet/, etc.) could be
kept for compatibility with the current implementation. An application
chooser (as in the open-with dialog) should use, in my opinion, the
same menu structure in the k-menu, as the user is already familiar with
that classification, plus an extra entry, eg. "Other", that includes
apps not listed in the user menu.

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

The MenuItems entry is required to keep the sort order of the added items.
For example, you might have:

MenuItems=Konsole,Kvt,SEPARATOR,Trashcan
AddedItems=Kvt,SEPARATOR

konsole and trashcan are inherited by upper level. The user has added
Kvt and SEPARATOR between Konsole and Trashcan. W/out the MenuItems key,
we cannot store the *position* at which the new items have been added.
As a side-effect, the merging algorithm isn't used when the local menurc file
is newer than other menurc files.

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

You can already have custom names for submenus modifing the "Name=" entry
in the .directory file. Probably I'll move this entry in the menurc file,
as you and others suggested.

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

I'll consider what you suggest, but for the first implementation I'll
not allow moving system-defined menus. I would like a simpler --but
stable-- version first.

Thanks for your suggestions,

-- Pietro

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