VFolders isn't a standard yet

[George]

On Tue, Jul 09, 2002 at 08:33:36AM +0200, Thomas Zander wrote:
> > 1) Suggest addition to the spec
> 
> Which will not be translated untill a new version of the spec will be implemented
> right?

Not really, the implementation shouldn't be anal and check that categories
are from the approved list.  So the new category would just work.

> 
> > 2) Use X-Product-Category format to add a new one.  There's already an
> >    X-GNOME-Sawfish category which is very GNOME specific currently and
> >    doesn't seem proper to be in the spec.
> 
> So you don't expect other desktops to show such icons? I can't imagine a new
> and former unpublished tag to be used by your menu.  Unless you hacked in a 
> string compare for exactly that catagory...
> Plus, can you add a .directory file for that catagory?
> Will the RPM alter my XML file to allow for a new catagory?

No, other desktops will just not use that category.  Each .desktop will have
multiple categories for which it gets queried, you can have as many as you
want and some of them just won't be used.  Its sort of like a keyword in a
database query (except we can't use the word Keyword as that's reserved
by KDE for something else in .desktop files)

Note:
Category != Directory

Directories are defined in the vfolder-info file and you will be able
to define a new .directory for that and define a query that will populate
this directory with .desktops.  Think of the categories as keywords!

> I'm not sure the base covers all, and I am getting the impression that you have not
> thought through a manner of using this beyond one static distribution set.

No, I have, read the spec and look at the .vfolder-info file that comes with
gnome2, I think it will make a lot more sense.

> > All the binary names are in one dir and you must make that up to be unique
> > ... just make up the .desktop file names in the same manner.  It's also much
> > easier for implementation.
> 
> That is what I said, yes. I also pointed out that there are problems with that
> approuch. Problems many people fall over.
> And your sole argument is that it is easier to implement?

No, my sole argument is that it is not a problem.  You can namespace
your .desktop files if you want:

company-or-project-name-program.desktop

or even:

GeorgeLebl-MyProgram.desktop

or:

SystemSetup-Frubargweed.desktop

Or whatever.  In the days of GUIs the length of binary name or the .desktop
file is not a problem since noone will be typing it in.

Same issues come for all other similar files on a system.  You just have to
namespace, that's all.

> There _is_ a way to do this in a backwards compatible manner and you choose to
> ignore it since its more work. Hmm, good luck in getting the patches accepted.

It's not just more work.  It's slower and more resource intensive to use more
directories, since you suddenly have to read and watch more directories then
one.  And since you can just namespace, having further structure just
complicates the issue, makes it harder to implement and also makes the
implementation slower and more resource intensive.

George

-- 
George <jirka at 5z.com>
   I thoroughly disapprove of duels.  If a man should challenge
   me, I would take him kindly and forgivingly by the hand and
   lead him to a quiet place and kill him.
                       -- Mark Twain