[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-25 18:59:44
[Download RAW message or body]

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

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