Reading the script.c code I understand, why nobody likes to change the params to have longer names... They are stored in table numerated by letter, 1 for a, 2 for b...
ubasic only permits one letter variables no matter what.
All that code is a pretty big mess. If it gets re-written, I'd like to see it become less of a mess.
Rather than extending the options screen, it might be better to come up with a way for scripts draw their own options screen. I'm thinking the script would be run with a special parameter, or a particular function would be run when the menu was accessed. It might be necessary to separate script selection from script configuration. The script would be given some primitives to draw things like enum values, numeric fields, text etc (mostly exist in drawings already). This would be fairly easy to do in lua, less so for ubasic. I'd personally be OK with require such scripts be in lua.
On the other hand it could be more intuitive if scripts only started in script menu: ALT-MODE-SHOOT wouldn't be much slower than ALT-SHOOT.
If we go this way, one option would be to use the func button. Currently it only opens the script menu. Instead, it could go to script mode. If you have a script selected, you are ready to shoot and pressing menu will bring up the script dialog. If you don't have a script selected, it would bring up the script dialog.
Would full shutter press anywhere else in alt mode then exit alt and press shoot_half + shoot_full?.
That's a good question. Another question would be what the other keys would do in script mode. For example, you could have left/right switch between option sets.
I kind of hate icon interfaces, at least on devices and features I don't use daily, mostly because it takes time to learn to associate a new icon with a feature and because many features just aren't well described with a small low resolution image.
Agreed.