:: Re: [DNG] Would you guys hate me if…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Hendrik Boom
Fecha:  
A: dng
Asunto: Re: [DNG] Would you guys hate me if...
On Fri, Aug 05, 2016 at 03:15:24PM -0400, Steve Litt wrote:
> 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,


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