VFolders isn't a standard yet

[Andreas Pour]

George wrote:
> 
> On Sun, Jul 07, 2002 at 10:39:42PM -0500, Andreas Pour wrote:
> > 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.
> 
> No, that's not the point.  The point of the vfolders is to be able to CHANGE
> the structure without effecting installers, installed programs and programs
> that will be installed in the future.
> Programs/installers should not care about exactly where their .desktop file
> is placed. If they do we are stuck with exactly ONE structure forever.
> This HAS been a serious problem in the past if anyone remembers when GNOME
> 1.4 came out and Ximian changed the directory structure.  And all non-Ximian
> software failed to show up in the menus.  With VFolders, new software would
> get placed in the correct submenus.

Hi,

What you seem to be describing, to me, is a design flaw in rpm, and
perhaps other package mangers.  A package manager that does not permit
moving files when installed is really the core problem, no?  And to
solve that problem, we create a monster directory with potentially
hundreds of files.

You know why people use folders?  B/c it is a very useful way for humans
to organize things.  This is reflected in the fact, that the menu
structure, even in the proposal, contains folders, and not one flat
directory.  The fact of going to all the trouble, to create the
conversions, proves that everyone agrees that a heirarchical layout is
the logical, understandable way to arrange things.

So while, under the current package manager state, I see the benefit to
the solution, I just wish to express the view, that this seems to me to
be more of a hack to work around a major deficiency in package managers,
particularly rpm, and I think it would benefit not only GNOME and KDE,
but all Linux users, if the corrections were made in the package
manager.  Corrections such as, at a minimum, being able to move, copy,
delete, rename, reparent and otherwise manipulate files in the package
database post installation, and, in fact, even during installation, such
that the user may have the benefit of providing some input, into how
files are spread around the file system.

I think, all the points you raise below, are premised on the same
deficiencies, and I would concur that they provide a sensible way to
work around them.

[ ... ]

Ciao,

Dre