On Sat, Aug 06, 2016 at 04:26:15AM -0400, Steve Litt wrote:
> On Fri, 5 Aug 2016 23:43:33 -0400
> Hendrik Boom <hendrik@???> wrote:
>
> > On Fri, Aug 05, 2016 at 03:15:24PM -0400, Steve Litt wrote:
>
> > > 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?

>
> Kinda sorta maybe.
>
> It's more like this:
>
> 1) Check the destination parent for a conflict with this menu letter.
>
> 2) As a human, decide what to change to resolve that conflict.
>

> 3) If anything was directly calling the old submenu as a menustring
>    (this happens quite often, especially when making a menu
>    persistent), change the letterstring of the caller.

>
> >
> > 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.
>
> It has a certain charm to it, doesn't it? It uses Linux' filesystem as
> a hierarchical database that the program can manipulate with lightning
> speed. And a human at a command prompt can work with it if he's careful
> and thorough.
>
> A human with a good file manager can have his way with the system.
>
> And I could easily make a Python Qt or a Lazarus program to
> create/modify a submenu or command.
>
> >
> > It could still be useful to allow links of some sort to submenus in
> > other files. That might permit better separation of concerns.
>
> How so? Do you have an example that might clarify the context?
>
> > 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,
>
> OHHHHHHHHHH!!!!!!!
>
> I see what you mean. Silly me. I always think in terms of "each user
> rolls his own," and never stop to think about packaging. I suppose a
> standard for menustrings (the sequence of menu letters to drill down to
> a submenu) could be made, and hopefully followed. There's one problem:
> One of UMENU's basic foundational tenets is that no submenu can have two
> occurrences of the same menu letter. It will fail if a submenu has two
> of the same menuletter. This makes discipline a little more important.

AH! I forgot about keystroke menus. I was thinking of mouse menus,
which have different kinds of convenience.

But I think mechanisms for resolving this -- or forbidding this -- are
probably a lot simpler than parsing an entire tree of menu items as a
file.

-- hendrik