On Sat, 6 Aug 2016 17:12:14 -0400
Brian Nash <bcnjr5@???> wrote:


> On Thu, Aug 04, 2016 at 02:36:06PM -0400, Steve Litt wrote:
> >The last two items on the preceding list are why deployment is so
> >problematic. On my system, each of my 237 submenus requires its
> >own .mnu (menu description) file. These are created by compiling,
> >through a program I wrote, a 4122 line s.emdl file. That compile
> >lasts over 2 seconds, which is why running a menu system directly
> >off an EMDL file can't happen. You see, every time you invoke a
> >submenu, you invoke a brand new UMENU executable. This works well,
> >it eliminates the need for a stack or client/server or the like, and
> >it's trivially simple. But it means that each and every invocation
> >of umenu must load and display in a fraction of a second.
> >
> >About menu system configuration: Chances are, I'll never find a
> >native format for the menu system configuration that is both: 1)
> >lightning quick on submenu startup, and 2) Lightning quick for a
> >person to modify, including moving whole branches.
>

> What about the linux kconf menus?
> (`make menuconfig`)
>
> Once menuconfig is compiled, it is executed with a Kconfig file passed
> as an argument. It loads the file (and included files) very quickly,
> and the Kconfig files are _massive_.
>
> After it loads the file(s), it parses them, then determines what
> should be disabled, etc. The whole startup takes less than a second
> on my "special" (read: slow) computer, IIRC.
>
> The whole program is pretty fast, and the Kconfig files are
> text-based.
>
> Maybe you could do whatever magic the kernel devs did, but with a
> different syntax?
>

After the horror of file conversion in UMENU v1, and especially after
what people on DNG have said about dir/file tree being a good idea,
more than ever I'm thinking a native format of dir/file trees,
supported by text editors, and/or file managers, and/or specialized
submenu config helpers, might be the way to go.

Given that my current design reloads the config file for each submenu,
"less than a second" is no good: It needs to be "less than .4 seconds"
at a minimum, and "less than 100ms" would be much better. Menus start
losing their competitive edge when you can type faster than they can
process your keystrokes.

SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
Brand new, second edition
http://www.troubleshooters.com/mgr