VFolders isn't a standard yet

[Havoc Pennington]

Hi,

I'm not sure what provoked the sudden interest in the vfolder spec,
but let me reiterate that no, it is not a standard. It is only a
proposal that George made.

It has been implemented in GNOME 2, and as mentioned here before Red
Hat intends to have KDE and GNOME read the same menus in Red Hat
Linux.  We will continue to read desktop files from /usr/share/applnk
and /etc/X11/applnk for back compat, so no third-party desktop files
will be lost.

We are planning to submit these patches upstream, but AFAIK do not
currently have any indication that they will be accepted. If upstream
solves the same problems in a different way in the future, we're
willing to move to that solution.

For now, I believe this is a legitimate integration feature, along the
lines of the Debian menu system. I understand that it causes a bit of
pain to have Red Hat specific patches for this, but I believe the
benefits of a single menu system outweigh that, and we are taking due
steps for compatibility by reading /usr/share/applnk.

Navindra Umanee <navindra at cs.mcgill.ca> writes: 
> This VFolders stuff seems needlessly complicated and overly ambitious.
> It tries to solve problems that aren't really much of a problem on
> most people's desktops (50 xeyes?) and it does this by trashing the
> simple and well-accepted concept[2] of fs-based hierarchical menus
> that both GNOME and KDE have successfully implemented and deployed.[1]
> 

George came up with vfolders for his own reasons.  However, it turned
out that George's ideas solved some real problems we had in Red Hat
Linux. When we went looking for solutions to those problems George's
proposal seemed to work, it was already implemented in GNOME, so we
decided to just use that instead of making up some third thing.

Here is what the vfolder spec buys you:

1. It was impossible to change which menu directories existed without 
   modifying a whole lot of packages, and "losing" third party 
   .desktop files. Ximian tried to change the menu hierarchy in one 
   of their releases and annoyed users by losing these files.

2. It was extremely difficult to rearrange the menus in different
   products. Imagine that we have a server product and a home
   product. You want different things to appear in the menus. 
   We should be able to do this by modifying one package, 
   not by modifying them all.

3. Sysadmins had a very difficult time modifying the menus, 
   because they had to change a lot of packages, and then on 
   upgrade things were hosed.

4. To share menus between GNOME and KDE using the directory system,
   you would need to get GNOME and KDE to agree on the names of all
   the subfolders. Which doesn't sound easy at all. Having the same 
   menus in GNOME/KDE is important.

5. You want the "OnlyShowIn" feature, where you use the integrated
   calculator for each desktop environment. (Not really vfolders per
   se, but also in the proposal from George.)

What this all comes down to is that the menu hierarchy should be in a
single file, not a directory hierarchy. 

Then we, and sysadmins, can enhance the menus by editing one file in
one package. I consider this a huge win. Also, sharing the same menus
between GNOME and KDE means that we, and sysadmins, have half as much
work to do.

So that is why Red Hat is enthusiastic. Or if you want, why I am
enthusiastic; as "Red Hat" in this context is basically me, if you
want someone to throw rocks at.
 
> Furthermore, I see no evidence that this proposal is being pushed or
> has been explicitly approved by the relevant KDE maintainers (I see a
> couple of side comments in the archives), though I note Red Hat's
> enthusiasm.  The proposal was described as being only a slight
> extension at some point, so perhaps the right people didn't pay proper
> attention?

I wish people would monitor this mailing list. :-/

In any case, I hope we can have a productive technical discussion and
resolve the issue. I would love to see alternative proposals, but
would really hope they maintain the single config file approach, as
it's quite useful.

Havoc