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

[Matt Kynaston]

On Mar 30, 2005 2:30 PM, Waldo Bastian <bastian at kde.org> wrote:
> Hi,
> 
> I would like to propose the attached change to the menu-spec, the explanation
> is given below.

Bump.

Is there anyone else interested in seeing this change make it into the
spec? Seems to me it adds needed functionality, makes the spec easier
to understand and has very limited BC impact.

Regards,

Matt

> 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.
> 
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
> 
> 
> 
>