David Beattie wrote:
> 
> But anyway, I hope it likes a usa.net free account better.

Seems to work :)

[SNIP]

> Moving of a menu item would be done by placing two configuration entries
> in the local menu file (for example, "Moved from=Utilities/KEditor.kdelnk"
> and "Moved to=Utils/KEdit.kdelnk").  Also, just as important, I would
> place a hard link to that local menu file in *both* places, so the file
> containing those above two entries would be in both
> locateLocal()/Utilities/KEditor.kdelnk and
> locateLocal()/Utils/KEdit.kdelnk.  
> When reading the menu from disk, KPanel
> would compare the file it is reading to the "Moved from" and the "Moved
> to" locations.  If equal to the "Moved from" location, the menu item would
> be marked as one not to display.  If equal to the "Moved to" location,
> though, the missing (because redundant, specified further up the
> hierarchy) data would be read from the "Moved from" location further up
> the hierarchy.  [Thus my "Moved from" location is the same concept as the
> "Origin" entry proposed earlier.]  This duplication of disk position for
> the menu entry (it could be a soft link instead of a hard link, I suppose)
> would allow KPanel to build any arbitrary submenu without reading the
> entire menu, and so would cut down on the complexity of the
> algorithm since it eliminates the need for inversion of data structures.

The latest idea was to seperate the contents of .kdelnk (now .desktop) files
and the location in the menu. Basically we would then just have a (menurc) file
which describes which entries should show up where in the menu.

Your mail made me realize that this has a disadvantage. When a new application
gets added to the system, this will most likely not show up in any user menu
since the user will have its own menurc file which will override the system
one. 

Your solution with a link to the original position and a "Removed from" line
seems to be pretty smart. Together with KStdDirs it will be very easy for
KPanel to implement things:


Some pseudo code for kpanel:

readMenu(relativeMenuPath)
{
   // relativeMenuPath is e.g. "Utilities"
   bool uniqueFiles = true; // Return only the most specific entry
   allFiles = findAllResources(".desktop", relativeMenuPath+"*.desktop", uniqueFiles);
   for (i=0; i < allFiles.count;i++) 
   { 
      thisFile = allFiles[i]; 
      // thisFile is e.g./home/joe/.kde/share/kdelnk/Utilities/KEditor.desktop

      filename = thisFile.stripPath();
      // filename is e.g. KEditor.desktop      

      relativeFilePath = relativeMenuPath+"/"+filename;
      // relativePath is e.g. Utilities/KEditor.desktop
      // NOTE: It would be nice if KStdDirs returned it like this itself.
      //       Would actually be easier for KStdDirs this way to filter out
      //       duplicate entries.
      contents = readDesktopFile(relativeFilePath);
      if (contents.removedFrom.isEmpty() )
      {
         addToMenu( contents );
      }
      if (contents.removedFrom = relativeFilePath)
      {
         // This entry is deleted from here.
         continue;
      }
      else
      {
         // Read info from the original location
         contents = readDesktopFile(contents.removedFrom)
         addToMenu( contents );
      }
   }
}

Deleting an item would mean adding "RemovedFrom = "+relativeFilePath to the
desktop file.

Moving would mean adding "RemovedFrom = "+relativeFilePath and adding a link
from the new location to the old location.

moveMenu( oldRelativeFilePath, newRelativeFilePath)
{
   oldLocation = locateLocal(".desktop", oldRelativeFilePath);
   newLocation = locateLocal(".desktop", newRelativeFilePath);

   Add "RemovedFrom = " + oldRelativeFilePath to File(oldLocation).

   link newLocation to oldLocation.
}

Pietro: Do you think this still feasible or have you already implemented
it the other way? This seems to work very smart. readDesktopFile should
just read the desktop file in the "shadowing" fashion we talked about
earlier on.

Cheers,
Waldo
-- 
The "gui" in "Penguin" is pronounced "K-D-E"