On Fri, 5 Aug 2016 04:29:53 -0400 Hendrik Boom <hend...@topoi.pooq.com> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng