On Fri, Aug 05, 2016 at 03:15:24PM -0400, Steve Litt wrote: > 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,
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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng