On Fri, Aug 05, 2016 at 03:15:24PM -0400, Steve Litt wrote:
> On Fri, 5 Aug 2016 04:29:53 -0400
> Hendrik Boom <hendrik@???> wrote:
>
> > On Fri, Aug 05, 2016 at 07:50:26AM +0200, Edward Bartolo wrote:
> > > Hi All,
> > >
> > > I suggest a simple text file to store all menu information in a
> > > format that doesn't require any specific parsers to be installed.
> > > Some argue and seem to have a point, XML is not that readable for
> > > many users and more often than not a tool is required to edit
> > > complex files. My suggestion is a simple format to keeps record of
> > > menu tree paths and the actual menu items as follows:
> > >
> > > placement="/path/to/menu/item/in/menu/tree"
> > > name="my cool menu"
> > > command="/path/to/command param1 param2 ..."
> > > icon="/path/to/icon"
>
> The preceding is pretty darn close to what I might be planning. Right
> now, UMENU has an MS-DOS like install, where merely copying the tree
> gives you the app. I'm probably going to keep it that way. So, assuming
> the top of the tree is called $UMENU, the tree looks like the following,
> assuming two menu systems called a and r, of which only r is detailed
> in the following diagram:
>
> $UMENU
> |--program
> | |--umenu.py
> | |--getch.py
> | `--umenu_library.py
> |--conf
> | |--whatever, if anything
> `--menu
> |--a
> `--r
>
> In the preceding, both "a" and "r" are roots of menu hierchies.
>
> Now consider a submenu in the "r" hierarchy, which is a subhierarchy,
> whose letter is "g" and perhaps whose letter string (the path taken to
> this menu) is "rdsg", representing the following path:
>
> r->data->spreadsheets->gnumeric
>
> This "g" submenu might look something like this:
>
> g
> \
> |--props
> | |--menutitle.u (Title atop menu, contains "Gnumeric Choices Menu")
> | |--choicetext.u (Choice string on parent, contains "Gnumeric")
> | |--type.u (command, menu or return) (Contains "menu)
> |--t
> | |--props
> | | |--menutitle.u (Contains "Gnumeric Menu For Taxes"
> | | |--choicetext.u (Contains "Taxes"
> | | |--type.u (Contains "menu")
> | |--a
> | | `--props
> | | |--choicetext.u (Contains "2014")
> | | |--type.u (Contains "command")
> | | |--dir.u (Contains "/home/slitt/tax/2014")
> | | `--cmd.u (Contains "gnumeric")
> | |--b
> | `--props
> | |--choicetext.u (Contains "2015")
> | |--type.u (Contains "command")
> | |--dir.u (Contains "/home/slitt/tax/2015")
> | `--cmd.u (Contains "gnumeric")
> |--b
> | `--props
> | |--choicetext.u (Contains "Book orders")
> | |--type.u (Contains "command")
> | |--dir.u (Contains "/home/slitt/bookorders/2016")
> | `--cmd.u (Contains "gnumeric bookords.gnumeric")
> `--q
> `--props
> |--type.u (Contains "return")
> `--choicetext.u (Contains "Quit")
>
> In the preceding, please remember that every node that's not a leaf is
> a directory, not a file. In the leaves, the filename is outside the
> parentheses, and the file's content can be deduced by the stuff in the
> parenthesis. The filenames of the leaves all have extension .u.
>
> The preceding system is fairly close to ultimate for the machine.
> Finding a given submenu is as simple as following a tree: Almost
> instantaneous.
>
> And the preceding system is human readable, human parsable, and to a
> degree human creatable. But...
>
> Human creatable is relative. Yes, adding a new node to the menu could
> be done quickly with a script. But moving a submenu from one subtree to
> another could take a few minutes,
Isn't it just a single
mv
command? Or maybe
ln -s
if you want the submenu to show up both places?
I actually like using a file hierarchy such as you've outlined. No
special tools needed, except perhaps one to check it for syntacticllly
correct contents.
>
> JSON's a nonstarter. End tags make authoring so slow as to be useless.
The JSON I saw wasn't XML-encoded. I saw no end tags, though it did
have matching curly brackets. See
https://en.wikipedia.org/wiki/JSON#Example
> If I choose choice 2, author into a single file and compile to
> directory/file tree, correctly defined YAML could definitely be both
> fast and readable.
It could still be useful to allow links of some sort to submenus in
other files. That might permit better separation of concerns.
But I suspect having each package include its own pieces of menu into
the maelstrom is more easily done with separate files and conventions
which directories they go into,
>
>
> >
> > Or even Lisp S-expressions.
>
> I don't know how to do that.
>
> >
> > Or, if you waant to be elaborate, which Steve probably doesn't, a few
> > menu-creating macros to be called from Guile.
>
> I made menu-creating macros from Bash one time, and they worked very
> poorly. I've done a tiny bit of Guile. What would make Guile better and
> menu creating macros than any other language? If I did this, someone
> would need to teach my how to handle and output strings in Guile: I can
> only make it work with numbers.
Only that S-expressions aren't all that different from JSON and YAML,
although they have more parentheses and no mandatory intentation. And
if you use it, generalizing to Guile is a natural thing to do. Once I
mentioned S-expressions, it was natural to mentino guile, just for
completeness.
-- hendrik
::
Re: [DNG] Would you guys hate me if…
