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? 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.
--
_________________________________________________
( Knowing just enough to be dangerous since 1998. )
-------------------------------------------------
o ^__^
o (--)\_______
(__)\ )\/\
||----w |
|| ||
signature.asc
Description: Digital signature
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
