On Sat, Aug 06, 2016 at 04:26:15AM -0400, Steve Litt wrote: > On Fri, 5 Aug 2016 23:43:33 -0400 > Hendrik Boom <hend...@topoi.pooq.com> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
