My biggest objection is that I'm not convinced it solves any real problem, so it doesn't feel like a good use of my time. Ensuring this change causes no harm seems likely to take a lot of my time.
My next objection is that it is likely to create problems, because now every part of the code has to gracefully handle the case where certain "standard" modules are missing.
Finally, as a person who answers a large fraction of the end user questions on the forum, #2 isn't a trivial issue for me.
All valid arguments. I only wish you had taken the time to present those earlier; that would have saved a considerable amount of resources on the other end of this conversation.
What is or isn't a module in CHDK is arbitrary, and the impacts of having a particular module present or not is not all obvious to users, so using the presence of modules as a way to customize the menu at install time does not seem like a good solution.
I believe I can now see the full picture. I had been confused by the improper application of the term "module".
Only what the CHDK code refers to as "simple modules" could be considered true modules. Out of these, 3 are hard-coded into the menus (_osd_le, modinsp and useredit). That leaves us with exactly two types of modules: Games and Tools.
I'd suggest moving all script libraries into A/CHDK/SCRIPTS, all games into A/CHDK/GAMES, all tools into A/CHDK/TOOLS, and all the rest into A/CHDK/LIB, but that would probably be too much to ask for given reyalp's limited time. However, I do suggest using the appropriate terms (i.e., scripting libraries, games, tools, and other libraries, respectively) from now on.
Usability issues notwithstanding, I got the following request via PM today:
Can you modify the sequence to allow user's to only accept the license agreements they need / want? So if someone doesn't accept an SDM or ML license, the installation sequence disables the ability to load those but still allows CHDK (assuming the necessary licenses for CHDK are selected).
That seemed very reasonable to me. However, as I started pondering a solution, it occurred to me that none would be complete unless Lua and uBASIC are also taken into account.
Suppose the user doesn't want uBASIC installed (and hence doesn't want to accept its license). Does that sound like too far-fetched a scenario?
I therefore suggest a compromise. Only the following changes are to be made:
1. Modules scanned at startup as implemented in
menus3.diff.
2. Module ID field added to CMenuItem as
proposed.
3. Menu item hiding implemented as proposed, but only in items that encompass entire "module" types (i.e., Script, Games and Tools).
I consider the above set of changes to be the absolute minimum required for proper modularity.
Should the
user menu improvements proposal be accepted, menus3.diff shall be applied in its entirety.
What do you think?
Edit: Updated link.
