Uhm, when you say "expose UI stuff though Lua itself", you mean that it should be the script's job to draw menus etc.?
What I had in mind was using C to actually draw them, but a lua table would describe the options, hold the values, and potentially contain code to handle more complex things like options with ranges or options that depend on other options. Properly implemented, it could still be as simple as the current system (i.e. defaulting to a handful of generic options, or a few simple lines in the script file that fill out a default menu)
The change in approach is that part of the script has to run when the user sets the options.
One thing lua makes very convenient is tying script and C code together in various ways.
One-letter variables are a plague indeed, but surely we could get rid of that limitation without changing the whole approach?
Sure, you could extend
@param X Number of fraks in the frobulatorto
@param NumFrobFraks Number of fraks in the frobulatorwithout much trouble. I'd probably throw the default in there somewhere too so you don't have to write each one twice
If you only ever want to use scripting for the kinds of things it's used for now, that's good enough (although the menus for things like the motion detection scripts are already pretty nasty) However, with something like lua, you can potentially do a lot more, and make the interface to complex scripts easier.
I'm not sure I buy the UBASIC being easier to write argument. Lua started life as a way to write configuration files, and can still be used that way. It's up to the implementer of the host application to expose it in a way that is easy to use.
ubasic OTOH is simple because it is limited, but from what I can see is still pretty quirky and more painful to integrate with C code.
Keep in mind this is random musing from someone who only recently started exploring the CHDK code. The real proof of any idea is someone having the motivation to code it, and users deciding it was better than what came before.
