VFolders isn't a standard yet

[Andreas Pour]

Glynn Foster wrote:

[ ... ]

> In an corporate environment, something that both GNOME and KDE [to my
> limited knowledge] have't ever really thought about up until now, the
> heirarchical menu scheme doesn't really scale all that well.

Hi,

Could you please detail what the scalability issues are?

My understanding of what the proposal is trying to address is the
following points:

  (1) menus should be editable by sysadmins, by modifying a file or
files, not by rearranging directory structure.

I'm not sure why this is important, particularly since a menu editor
provides an implementation abstraction.  What makes it preferable to
sysadmins to modify files rather than move files?  I'm curious about the
feedback you have received which leads to this conclusion.

  (2) GNOME and KDE should share the same .desktop files (and hence have
the same menu layout), while prefering a native solution for certain
integrated desktop functionality (such as the panel or calculator).

This seems like a good point, but, I'm not sure how using a flat
structure for .desktop files addresses this issue.  It does seem quite
sensible for KDE and GNOME to use the same "root" for .desktop files, so
when an application is installed, it provides a single .desktop file and
this is seen in both the KDE and GNOME menus, preferably in the same
submenu.  However, simply changing this root is a far less drastic
change than the proposal, which is incompatible with the existing method
(and I do bear in mind, that a lot of criticism of late has focused on
the lack of backward compatability).

As to preferring one panel, etc. over the other, I also do not see how
changing from a heirarchical directory structure to a flat one and using
a new .desktop field helps resolve this particular issue.
 
[ ... ]

> Let me repeat, the vfolder spec *only* contains 2 things -
> 
>         a) agreement on a standard location for .desktop files
>         b) addition of the 'Categories' key in the .desktop file and
>            suitable values for this key.

What are these "suitable values"?  Is there a draft of the specification
for that?

Is this key then mapped to an actual submenu on a distribution-specific
basis, or will this key actually constitute the submenu for the
application?

How are translation issues addressed for the key, if there is some
mapping, since the project translation team will not be able to provide
a translation of the menu folders any longer?

Ciao,

Dre