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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng