menu-spec: Making menu-editing work, cleaning up <Move> semantics

[Waldo Bastian]

Hi,

I would like to propose the attached change to the menu-spec, the explanation 
is given below.

Cheers,
Waldo

Summary
=======

Currently the <Move> element contains the following normalization requirement:

--Quote--
A move must reside at the lowest possible point.

In other words, all moves have exactly one permissible location in the <Menu> 
hierarchy. Implementations can trivially detect violations of this rule: the 
<Old> and <New> paths may never share a common prefix. Moving "Foo/Bar" to 
"Foo/Baz" must be done with a <Move> element that's a child of the "Foo" 
<Menu>, i.e. by moving "Bar" to "Baz", not by moving "Foo/Bar" to "Foo/Baz".
--End Quote--

There is no real benefit or justification for the above requirement. Instead, 
it makes it unnecassery difficult to use the <Move> element for menu-editing 
purposes.

I propose to drop the above normalization requirement and add a recommendation 
that for menu-editing purposes, <Move> elements are only added at the root 
menu and never to any sub-menus. In addition, the order in which <Move> 
elements are recursively processed should be changed from breadth-first to 
depth-first in order to make the results of additional <Move> elements more 
predictable.

Notation
==========

I will use the following notation in this e-mail to indicate a move operation:

	/A/B: C/D --> E/F

This means "Move the menu /A/B/C/D to /A/B/E/F by adding a <Move> element as 
child of the /A/B menu" as per the following XML:

<Menu>
    <Name>A</Name>
    <Menu>
        <Name>B<Name>
        <Move><Old>C/D</Old><New>E/F</New></Move>
    </Menu>
</Menu>

Normalization brings no benefits
=======================

The justification for normalization is that it allows easy detection of 
duplicate moves. However, this is both insufficient and unnecassery. It is 
insufficient because the spec calls for detecting moves that are literal 
duplicates, but not for moves that are logical duplicates, as such it doesn't 
accomplish anything. It is unnecassery because a duplicate move has no 
effect: the section on menu merging explains that if the origin path of a 
move does not exist, nothing nees to be done.

Normalisation says that the sequence
	/: A/B/C/D --> A/B/E/F
should be expressed as 
	/A/B: C/D --> E/F
instead. However, any sequence 
	/: A/B/C/D --> A/B/E/F
can be converted into a two step sequence of the form:
	/: A/B/C/D --> X
	/: X --> A/B/E/F
that does meet the normalization requirement. Such a sequence is the logical 
equivalent of the second sequence, yet it is litteraly different and as such 
will not be detected as a duplicate by the current spec.

In fact, duplicate removal of moves can be harmful. Just look at the following 
sequence:

	/: A/B/C/D --> X
	/: X --> A/B/E/F
	/: A/B/C/D --> X

The spec currently says:
--Quote--
Resolve duplicate <Move> operations (with the same origin path) by keeping the 
last one.
--End Quote--

So the resulting move sequence will become:

	/: X --> A/B/E/F
	/: A/B/C/D --> X

In other words, the addition of an additional move has efffectively broken a 
previous functional move sequence.


Nomalization makes menu editing unnecassery complex
==================================

Due to normalization it becomes very hard to use the <Move> element for 
implementing menu-editing. Ideally, a menu-editor should be able to express 
menu editing operations by appending a simple menu transformation to the 
existing menu file. The normalization requirement breaks this approach as 
shown in the following example:

Assume the following menu-editing operations that a user performs over the 
course of 3 days:

Day1:
	/: A --> B/C/A
Day2:
	/: B/C/A --> B/D/A
Day3:
	/: B/D/A --> /E

Effectively the user has now moved menu /A to /E. Due to the normalization 
requirement a menu-editing tool can not use the above sequence but must 
normalize the move done on day 2:

Day1:
	/: A --> B/C/A
Day2:
	/B/: C/A --> D/A

The section on menu-merging now states that such move should be handled after 
the other two moves that were defined for the root node:

--Quote--
After recursing once to remove duplicates, resolve <Move> elements for each 
menu starting with the top level and recursing into child menus. So the 
deepest menus have their <Move> operations performed last.
--End Quote--

On day 3 we will now run into problems, because adding the
	/: B/D/A --> /E
move will not result in this move being done last, instead the order in which 
the moves will be processed becomes:

	/: A --> B/C/A
	/: B/D/A --> /E
	/B/: C/A --> D/A

So instead of effectively moving /A to /E, the sequence effectively moves /A 
to /B/D/A

Note that if the evaluation order for <Move> elements would be depth-first 
instead of breadth-first, the processing order would be different, but still 
incorrect:

	/B/: C/A --> D/A
	/: A --> B/C/A
	/: B/D/A --> /E

Instead of effectively moving /A to /E, it now has effectively moved /A 
to /B/C/A

In order to generate correct results, with the current menu-spec the 
menu-editing tool will need to convert the whole sequence on day 3 to:
	/: A --> /E
	/: B/C/A --> /E
	/: B/D/A --> /E

This is unnecassery complex.

The processing order for <Menu> elements should be changed
=====================================

Menu-editing tools do not wish to actually change the existing menu-file. They 
may even be unable to since the menu-file in use is most likely owned by a 
different user (root). Instead, a menu-editing tool will want to merge in an 
additional file that represents all the changes made with the menu-editor. 
For this it is important that the changes are processed after all other 
menu-files are fully processed, in particular, <Move> elements in existing 
menu-files should be processed before any of the <Move> elements generated by 
the menu-editing tool are processed. This is only possible if menu-editing 
tools add all their <Move> elements to the root-node of the menu and if 
<Move> elements are processed depth-first.

Backwards Compatibility
===============

The effect of these proposed changes wrt backwards compatibility will be 
limited. Only menu-editing tools are likely to produce complex sets of 
interacting <Move> elements to such an extent that the proposed changes will 
result in actual different menu results. I am not aware of any menu-editing 
tool available today that takes the pitfalls provided by the current 
menu-spec as outlined above correctly into account.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: menu_spec_move.diff
Type: text/x-diff
Size: 5457 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050330/f2d225ad/attachment.diff