XDG menu categories [more]

[James Richard Tyrer]

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 
tags.

Specifically:

              <And>
                  <Category>Science</Category>
                  <Not><Category>Math</Category></Not>
              </And>

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 
solution.

The obvious solution would appear to be to have the non-orthogonal tags 
have some type of hierarchy.

Would this work:

	Categories=Application;Office[a.2];Spreadsheet[a.1];

	Categories=Application;Education[a];Science[b.2];Math[b.1];

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:

	Categories=Application;Office;Spreadsheet;

	Categories=Application;Education;Science;Math;

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).

--
JRT

PS:  Donning flame retardant clothing, I am CCing this to the XDG list. :-)