From 5128e55ac6d14a2bc4a8b1522c03782cddbe734d Mon Sep 17 00:00:00 2001 From: Waldo Bastian Date: Wed, 13 Apr 2005 13:32:12 +0000 Subject: Change semantics and remove restrictions on element to facilitate menu editing. --- menu/ChangeLog | 5 +++++ menu/menu-spec.xml | 49 +++++++++++++++++-------------------------------- 2 files changed, 22 insertions(+), 32 deletions(-) diff --git a/menu/ChangeLog b/menu/ChangeLog index 0a19e5f..ace3601 100644 --- a/menu/ChangeLog +++ b/menu/ChangeLog @@ -1,3 +1,8 @@ +2005-03-30 Waldo Bastian + + * menu-spec.xml: Change semantics and remove restrictions on + element to facilitate menu editing. + 2005-03-23 Waldo Bastian * menu-spec.xml: Clearify DTD conformance and version compatibility diff --git a/menu/menu-spec.xml b/menu/menu-spec.xml index 0da49e7..1742485 100644 --- a/menu/menu-spec.xml +++ b/menu/menu-spec.xml @@ -1,6 +1,6 @@ + ]> @@ -789,24 +789,9 @@ entries: Categories, with the new folders. - <Move> may or may not be useful for implementing menu + <Move> is also useful for implementing menu editing, see . - - Duplicate <Move> elements are merged as specified in . Note that duplicates (two moves of - the same path) can be detected easily because of the following - rule: 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". - @@ -1009,12 +994,6 @@ entries: Categories, and so forth. - - - Resolve duplicate <Move> operations (with the same - origin path) by keeping the last one. - - Recurse into each child <Menu>, performing this list of @@ -1024,9 +1003,10 @@ entries: Categories, - 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. + After recursing once to remove duplicates, recurse a second time to + resolve <Move> elements for each menu starting with any child + menu before handling the more top level menus. + So the deepest menus have their <Move> operations performed first. Within each <Menu>, execute <Move> operations in the order that they appear. If the destination path does not exist, simply relocate the origin <Menu> element, and change its <Name> field to @@ -2002,16 +1982,21 @@ entries: Categories, <Include><Filename>foo.desktop</Filename></Include>. - If the user moves a folder, you might try to use <Move> elements - to represent that, but it's tricky. (Move A/B/C to D/E/F, then move D/E - to D/G, note that D/E/F still contains A/B/C while only the original D/E - was moved to D/G.) In order to move a folder, you have to "fix up" - all moves that move things into the folder being - moved to instead move things into the folder's new location. + If the user moves a folder you can use <Move> elements + to represent the move. <Move> elements used for menu-editing + should always be added to the most top-level menu to ensure that moves + are performed in the order in which they are specified; moves specified + in child menus are always performed before moves specified in a more + top level menu regardless of their location in the menu file. To delete a folder, simply append the <Deleted> element. + + When adding a new folder or moving an existing folder, menu editing + implementations are advised not to re-use the menu path of a previously + deleted folder. + Menu editors probably need to do some kind of consolidation/compression to avoid an XML tree that grows infinitely over time. -- cgit v1.2.3-70-g09d2