Personally I prefer to use User Menu as root menu to hide most unused in common use case items. If I need edgeovr, I could easily map it.
This does not automatically mean everyone else uses the 'user menu'. Probably most CHDK users are not even aware it exists.
I do not like binding to modules static menu, because this cancel extensibility of modules.
How does this affect the extensibility of having modules?
A new / test module will still appear in the file browser and 'modules menu' and can be run from there.
If someone wants to add a new module that has a U/I then adding a menu item into the core is not a big deal.
If the module file does not exists the loader can pop up an error message.
The existing compile time options can be used to remove the menu options for those users who want to compile a custom version.
PS 1. I see no big deal if menu reorganized slightly. And moreover I think that many items could be simplified, so menu will be even more different.
This is a big deal - the current structure may not be ideal; but it has been in place for a long time and is familiar to users. Changing it will also require updates to all the wiki documentation.
PS 2. Games menu could be restored(but in slightly different place) and could be mapped to UserMenu with no effort. Just create Games subdirectory in A/CHDK/MODULES/ and place games there. Only one reason why this is not default make way is possible path size issue on old camers.
As you point out this won't work because it will break on many cameras that have the 32 character limit on file/path names. Static menus don't have this problem.
In my view, having the ability to manage the menu structure (and keep the existing structure) regardless of whether the code is in the core or a module is a better pattern than tying the menu structure to the location of the code.
Finally there is still the issue of cameras crashing on startup if CHDK does a lot of file I/O - have you solved this problem on the S95? Can you guarantee that it won't be a problem on other cameras? As I said previously, until this problem is resolved
for all cameras the dynamic module / menu creation is probably best avoided.
Anyone else have any thoughts on this?
Phil.
