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, instead of the 10 seconds it takes
with the current EMDL. And with such hassles, people won't actually
maintain their menu. That's no good at all.

This leaves three choices, as I see it:

1) Have a single-file source format that gets compiled into the
directory tree. Kind of a hassle; the type of hassle that
contributed to the undeployability of UMENU version 1.

2) Make a drag and drop or cut and paste GUI app to assist in
making/maintaining the directory tree. This is easiest for the user,
but is difficult to create, and unless there's another way
available, makes the user highly reliant on this app.

3) Make a bunch of scripts to help in creating/maintaining the tree.
This sounds like a great idea, especially to Devuan type people, but
I make such a set of scripts for UMENU1, and it quickly became clear
they were of little value.

4) Rely on an existing filemanager to help the user do the work.
Rox-filer comes to mind, although it's a real shame rox-filer is so
mouse-centric. With a few templates already created, the rox-filer
method seems to me (I've not tried it) like it might be easy and
fast enough.

> >
> > Empty lines should be easily skipped but for human readers they
> > make a text file more readable.

Yes. UMENU1 already deletes all to the right of an unescaped pound
sign, and all lines that are "^\s*$". This is a must. With the
directory/file construction, there's actually very little need for such
stuff.

>
> Or something more nestable, such as JSON or YAML. No. You don't
> have to use Java to use JSON.

JSON's a nonstarter. End tags make authoring so slow as to be useless.
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.


>
> 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.

>
> >
> > For a simple use case like this, I don't think using a dependency on
> > MongoDB is justifiable.

Yes, I've had other feedback that agrees with you.

> >
> > I can easily write a C function to parse this file. Steve Litt if
> > you want I can write a couple of functions for you but give me the
> > variables in which you prefer to have the file read.

With the possibility of the "get character without needing the user to
press Enter" functionality, there will be no C in this. Who needs
the compilation, who needs the security problems? I've rewritten UMENU1
in Perl, Python, Ruby and Lua, and can tell you that all four ran it at
a sufficiently crisp speed to be pleasing to the user. As I mentioned,
at least from my "upstream" point of view, installation is as simple as
dropping a tree somewhere, cd'ing to that tree's ./program directory,
and running umenu <menustring>.

SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
Brand new, second edition
http://www.troubleshooters.com/mgr