Dev Request: UI for mapping functions to buttons

[Marsu42]

The smaller camera models, and even the bigger ones like 60d are not very good at customization - Canon only allows for a very limited mapping like some functions to set. With ml it's generally easy to implement a more extensive system, I just added a non-lv meta key with timeout similar to the lv-shortcuts function.

The problem is that I can either hardcode some function mapping (what button does what), but with the current menu system is not designed to do a n:m mapping of one of all available functions to one of all available buttons that generate an event code. It's the same with the 600dplus Rebel ui in the recent pull request, there's no way for the user to choose what arrow keys do what.

Imho it would be a great step forward for ml if there would be a pretty ui that visualizes all available buttons, lets the user select them and then choose what functions should be mapped. There are plenty of Canon and ml functions that would be nice to toggle without going through the menu - either on/off functions (for example bracketing on/off) or binary toggle keys (for example toggle between one shot and servo af).

I'm not able to code such an ui, but I'd like to propose the idea to the people who are if the idea seems reasonable?

[peter.scharff]

Yes I've suggest this also too Marsu42, main reason being I would like a dedicated button to open the flash menu (straight to ratios menu), some options are buried way to deep to work with how I like to work on my 5D III.

[g3gg0]

i recommend to implement this as module.
sure, it wont work yet fully because intercepting key presses is not possible yet, but
we can easily implement such callbacks with the current architecture.

see https://bitbucket.org/hudson/magic-lantern/commits/72cb65c487cd1eb67229012dea5631e3a0b36a28
in file shoot.c how to call module CBRs (callback routines).
then just add a CBR like CBR_KEYPRESS and pass the return value.

[a1ex]

Well... since the modules don't support any camera-specific code, and the button codes are camera-specific, this won't work.

With PicoC I've tried to implement a platform-independent key handler (will work as long as you use the constants and not the raw numbers).

[Marsu42]

i recommend to implement this as module.

Is there any inherent code difference between module & core code, except for the obviously missing functions alex mentioned?

That's why I personally don't really care where this ends up, it's just that I'd like to ask you if you see any need for this or I'm the only one... unfortunately doing ml graphics or fancy programming is beyond my knowledge level or time budget, but I'd really like to use such a n:m key->function mapping framework because Canon's customization options on the cheaper cameras and even xxd like 60d are really disappointing.

[g3gg0]

there is basically no difference on the C code level.
its the same as if you added a new .c file and put your new code there.
task/init and prop handler stubs are your only interfaces.

when i am back from the states, i will add return values to callbacks plus a callback for keypresses,
so modules can intercept them and block/pass the messages if needed.

[Marsu42]

when i am back from the states, i will add return values to callbacks plus a callback for keypresses,
so modules can intercept them and block/pass the messages if needed.

Sounds good, it'd be a good way to add code to ml w/o merging problems - as far as I understand it alex implemented menu hooks for modules, and if you add key & prop (set/get) handlers everything should be there.