Hi all,

I asked a hypothetical question about dependencies, using a menu
program as an example. 3/4 of you were more interested in the nature of
the menu program than in its dependencies. Well, the good news is,
version 1 of this program, called UMENU, has existed since 1999 and in
its present form since about 2004, so I can answer your questions.

http://troubleshooters.com/umenu/

And a couple screenshots:

http://a3b3.com/stuff/umenu_screenie_mainmenu.png

http://a3b3.com/stuff/umenu_screenie_application.png


It's a wonderful program whose deployment is a horrific mess. Version 2
deals with the deployment problem: At runtime version 2 will act exactly
as it does in version 1. UMENU1 has the following features:

* 100% text user interface
* No need to press Enter after making selection
* Cannot accommodate multiple items on one menu having same invoke
letter. (Slight functional compromise brings great simplicity)
* Can be used on a terminal, a virtual terminal, a GUI terminal
emulator, or a teletype machine with paper.
* Submenu appears within .1 to .2 seconds (fast)
* Ugly (good)
* Each submenu has its own menu descriptor file (horrible)
* Menu descriptor files made by running Easy Menu Definition Language
(EMDL) file through a program (bad)

The last two items on the preceding list are why deployment is so
problematic. On my system, each of my 237 submenus requires its
own .mnu (menu description) file. These are created by compiling,
through a program I wrote, a 4122 line s.emdl file. That compile lasts
over 2 seconds, which is why running a menu system directly off an EMDL
file can't happen. You see, every time you invoke a submenu, you invoke
a brand new UMENU executable. This works well, it eliminates the need
for a stack or client/server or the like, and it's trivially simple.
But it means that each and every invocation of umenu must load and
display in a fraction of a second.

I've been using the UMENU, as described above, for 18 years, and from a
use standpoint it's wonderful. But, as I said, it's a deployment
nightmare.

The only ways I can think of to run single menus off the entire menu
system config is either:

1) Keep the entire config in a directory/file tree, or
2) Keep the entire config in a quickly queryable database, hence the
question about Mongodb.
3) Keep some vestige of UMENU running at all times (and I don't like
that).

About menu system configuration: Chances are, I'll never find a native
format for the menu system configuration that is both: 1) lightning
quick on submenu startup, and 2) Lightning quick for a person to
modify, including moving whole branches.

When I said version 2 will have the same user-viewpoint features as
version 1, I lied. I want version 2 to have:

* Optional ability to order submenu items as desired
* Optional onscreen pointer to the "current item"
* Optional counter to keep track of which item was done last
* Total separation between screen reads/writes and submenu
construction. This allows others to write other, probably prettier,
front ends to UMENU. Also, this spits in Poettering's face :-)

UMENU has two uses:

1) Additional system menu that is keystroke quick (no Enter key), and
survives changes in and updates to your window manager. The first
screenshot I mentioned is an example. Now that dmenu exists, this is
not as pressing a need, but I still use it several times a day.

2) A front end you can "bolt onto" a no-user-interface executable you
created. The executable gets input from arguments and environment
variables, supplied by UMENU. UMENU gives an easy, discoverable
front end to the executable. This is a lightning quick way to create
an executable.

I'm so busy I don't know when I'm going to do this, especially since
the current UMENU works perfectly for me and two or three other people
on the planet. But sooner or later I'll make version 2 so everyone can
benefit. I'll write it either in (ubiquitous) Python3 or (lightning
fast) Lua. Using C for this would be swatting a fly with a cannon.

Thanks,

SteveT

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