Hi,

I am glad that the VFolder proposal has got more attention on the KDE
lists, I think it makes a lot of sense. I have been thinking on my own
about this for quite a while, and previously made some postings here about
menu hierarchies etc. I hope we can all agree that one menu hierarchy can
never please all, and that there should be ways to build custom
hierarchies for different purposes.

Now, how to do this? I would like to see a system where some kind of
database is queried and the menus are built according to the query. The
queries can be different however. I may want to browse applications in
many different ways. Look at freshmeat for example, you can browse by
Development Status, Environment, Intended Audience, License, Operating
System, Programming Language or Topic (which is most similar to how
desktop menus look today). I can easliy think of a couple of others which
would be good, usability wise, and others which are kind of redundant in a
a menu context.

The VFolder proposal is good because it separates menu hierarchies from
application metadata. No specific hierarchy is implied. Hierarchies could
be built differently depending on the query of the metadata. What is
missing, but could be a community effort on its own, is defining different
kinds of keywords for different properties of applications. For example,
both vi and nedit are editors, but not both of them are suitable to
display in menus for a beginner. So they could have different Complexity
tags in order to show only "easy" programs for beginner users. (As a
sidenote, I think it is strange to have an Internet category side by side
with a Games category. Games can use the internet, and today internet
awareness should be seen as a property of programs, not a category of the
same kind as Games. There are many examples of this in current
hierarchies. However, you may well want to browse programs with
communication abilities, but this is a different kind of property to view)

In the VFolder proposal the .desktop files hold metadata about
applications that can be started. This directory can be seen as a simple
but easily extensible database. I mean easily extensible because over time
the community can come up with other ways to categorize applications (for
example by Complexity, as above) and then this can be added as a new
keyword to the files. I have no strong opinions about whether or not the
files should all be in the same directory, but there is one advantage in
having them in the same as no hierarchy is then implied.

Last, there was mentioning here of the Debian menu system. I would like to
point out that Debian may use something like keywords for package browsing
(http://people.debian.org/4~BCerich/woody+1/ ). It is quite exciting that
there now is a great opportunity to build a shared "keyword database" for
different kind of keywords. I have been thinking of starting a Sourceforge
project on this, btw. There should be a large, but finite set of keywords,
for different properties of applications, and if there is consensus on
these keywords, they could be used to query package managers, as well as
start installed applications from menus or browse Freshmeat and the same
time easily be translated. It is more complicated than it first may seem
to identify different properties of programs and then find good keywords
that are applicable to most of them. I am on vacation currently, but if
there is interest I can share my notes on this in a few weeks.

Regards,
Claes