Re: vfolder .desktop and Window Maker
On Wed, Feb 19, 2003 at 05:46:10PM -0500, Havoc Pennington wrote:
> > <-- An Office submenu, specified inline -->
> > <Menu>
> > <Name>Office</Name>
> > <Directory>Office.directory</Directory>
> > <Include>
> > <Category>Office</Category>
> > </Include>
> > <Exclude>
> > <Filename>foo.desktop</Filename>
> > </Exclude>
> > </Menu>
> The <Name> is used in a URI-type thing such as
> applications:///Office/foo.desktop in nautilus. It would also be used
> for menu merging purposes. Think of it as a directory name.
Yes, I think I see it now. <Directory> specifies a file to be read,
which contains the name of the directory. <Name> OTOH specifies a
non-localizable string to be used by e.g. programs. (Think "Program
Files" mess in Microsoft Windows)
This:
<Include>
<Category>Office</Category>
</Include>
goes thru all the available entries and selects only the ones with
category "Office". I had missed this bit initially. I thought the
directory specified which entries to include. After rereading I see
that's not the case.
This means you parse all the menu entries, and then apply selectors to
decide which entries go in which menus.
What I am missing here is the ability to merge small menus into its
parents. For example, given this:
Tools/
Clocks/
Asclock
Archive Generator
Search Tool
"menu" will merge Asclock back into "Tools" because the "Clocks"
submenu is too small. You can see it from another POV: Asclock is
initially in the Tools menu, and has a "hint" named "Clocks". Iff
there's at least a certain number of menu entries with the same
"Clocks" hint, they will be grouped in the "Clocks" submenu, otherwise
they will be left in tools. This way you can avoid creating large
menus by creating deeper hierarchies and you avoid deep hierarchies of
sparse menus.
Marcelo
Reply to: