XDG menu categories [more]
James Richard Tyrer
tyrerj at acm.org
Thu Feb 12 22:54:59 EET 2004
Long title: Do non-orthogonal XDG menu categories imply a menu structure?
If so, should it be an explicit hierarchy?
Is this going to cause problems down the road?
After a minor flame war on the 'xdg' list, and my being told that I don't
know how the vfolder menu system works. You all should know that I really
hate it when that happens. Right, the retired engineer doesn't know
anything! Well I may not know a lot about this, I did a quick read of the
standard (to modify system's my menu). However, I do know about the
general concepts involved.
So, getting back to our example. It appears that following the standard
that all 'desktop' files for Math applications would contain both the Math
and the Science category tags. These two tags are not orthogonal -- the
tag KDE (for example) is orthogonal to Math).
My question is basically, what is the intent of this (using multiple
non-orthogonal tags)? Is it intended that the entries will appear in more
than one menu division? That would not be correct in this case since I do
not think that we want all Math applications to appear in Science as well.
So, it appears to me that this implies a hierarchy where Math is a subset
of Science. If that is the case, this will cause no problem since if the
category Math does not have a sub-menu of Science then it would appear in
Science. This would be the case for all subdivisions (subsets) of Science.
However, it causes a problem if you wish to create a separate menu entry
for Math which is at the same level as Science. Then the Science menu
entry -- NOT the Math menu entry -- needs to be aware of the non-orthogonal
This already is the case for the Education tag.
Although the solution for Math and Science is simple. The 'desktop' files
for Math applications should not contain Science. Then if we wanted to
include Math in the Science menu all that would be needed would be an
'include'. The && ! would not be required. This appears to be a general
problem. If it is a general problem, then we should consider a general
The obvious solution would appear to be to have the non-orthogonal tags
have some type of hierarchy.
Would this work:
Where the letter is indicates an orthogonal dimension in N-space -- all
tags with the letter 'a' are considered to be orthogonal to tags with the
letter 'b', etc. -- and the number is the 'hierarchy'. The tags would be
preprocessed, so if a menu category with the tag 'a.1' exists then the tag
with 'a.2' (or 'a.3' or 'a.4' etc.) would be ignored and not passed to the
code that uses the XML template. Tags without this would not be
preprocessed before they went to the XML template based menu code.
Alternatively, just working with the current tags we could do the same thing:
In the preprocessing, the order would matter in the usual manner where the
tag read last would override the previously read one (if the menu category
for the last read tag existed). But this should only happen if the tags
are non-orthogonal. So, that part of the code would have to be aware of
the menu tree structure (which would appear doable) -- if there was a menu
entry reachable by going only towards the root of the menu tree then it
would be non-orthogonal and would be replaced (overridden).
PS: Donning flame retardant clothing, I am CCing this to the XDG list. :-)
More information about the xdg