Menu vs module improvements (split from patch thread) - page 4 - General Discussion and Assistance - CHDK Forum supplierdeeply

Menu vs module improvements (split from patch thread)

  • 36 Replies
  • 5131 Views
Re: Menu vs module improvements (split from patch thread)
« Reply #30 on: 20 / June / 2017, 16:45:37 »
Advertisements
I implemented the aforementioned code changes (there are more than initially anticipated) and pushed to GitHub.

I tested extensively (save for touch, since I don't have a touch device to test on), and it's mostly bug-free. However, in one edge case, namely with both Games and Tools added to the user menu, the camera won't boot.

Could anybody who's familiar with the menu system please have a look?

Thanks

P.S.
Have you checked whether scanning 4x actually takes a meaningful amount of time?

I tested it on A550, and there is a noticeable delay during Games or Tools submenu creation in trunk.

Edit: Added screenshots.
« Last Edit: 20 / June / 2017, 17:13:34 by dmitrys »
Author of CHIMP, Canon Hack Installation and Management Platform

*

Offline reyalp

  • ******
  • 11919
Re: Menu vs module improvements (split from patch thread)
« Reply #31 on: 20 / June / 2017, 17:17:57 »
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.
Sorry I wasn't clearer earlier.

A few initial comments. I'll try to respond to more later.
Quote
I believe I can now see the full picture. I had been confused by the improper application of the term "module".
In CHDK, "module" just means a .flt binary separate from the core executable, roughly equivalent to a dll or shared library on other platforms. The primary reason this system exists is because of the very limited RAM available to CHDK. Some are self contained but this is only because they happen to implement a self contained features.

Auto-populating the tools and games menus is a small bonus that makes it relatively easy for people to drop in something that isn't part of "standard" CHDK.

Quote
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.
SCRIPTS is for script code, to make it so you don't need to sort through other stuff when loading a script from the menu. Putting script engines would be counter productive. For the others, I don't really care, but I don't see any actual need to divide them up. It's like /usr/lib...

Quote
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 would say yes, it's far fetched. IANAL, but as far as I understand uBASIC and Lua licenses are even more liberal than the GPL, and none of them impose any real obligation on end users beyond acknowledging that no warranty is provided. And honestly, who reads EULAs anyway?

Scripting is very much a core part of CHDK, so I am strongly opposed to allowing installs without the script engines installed. Note that PTP functionality depends heavily on Lua even if you don't want to run standalone scripts.

Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3107
    • Photos
Re: Menu vs module improvements (split from patch thread)
« Reply #32 on: 21 / June / 2017, 04:04:16 »
Usability issues notwithstanding, I got the following request via PM today:

Quote from: anonymous
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.

If you're going to get fussy about license agreements then you really shouldn't be supporting SDM at all.
SDM itself is a huge violation of the CHDK GPL license.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)

Re: Menu vs module improvements (split from patch thread)
« Reply #33 on: 21 / June / 2017, 10:15:42 »
SCRIPTS is for script code, to make it so you don't need to sort through other stuff when loading a script from the menu. Putting script engines would be counter productive. For the others, I don't really care, but I don't see any actual need to divide them up. It's like /usr/lib...

I'd say "simple modules" are part /usr/bin, part /usr/local/bin, but we're not trying to be POSIX-compliant here ;)

Quote
I would say yes, it's far fetched. IANAL, but as far as I understand uBASIC and Lua licenses are even more liberal than the GPL, and none of them impose any real obligation on end users beyond acknowledging that no warranty is provided. And honestly, who reads EULAs anyway?

SDM claims to be GPL, which is exactly the same as CHDK, and yet more than a few people around here don't like the idea of accepting its license.

Quote
Scripting is very much a core part of CHDK, so I am strongly opposed to allowing installs without the script engines installed. Note that PTP functionality depends heavily on Lua even if you don't want to run standalone scripts.

So that's why PTP upload stopped working!

Anyway, I'm planning on warning the user if they failed to accept Lua/uBASIC licenses, something like:

Quote
The following components require that their respective licenses be accepted:

Lua
uBASIC

Press Yes to go back to Licenses, No to proceed, or Cancel to abort the installation.

Lua will also be a part of any installation type (save for Custom of course). As for uBASIC, I'm not sure there are too many people who are still using it.
« Last Edit: 21 / June / 2017, 10:17:53 by dmitrys »
Author of CHIMP, Canon Hack Installation and Management Platform


*

Offline reyalp

  • ******
  • 11919
Re: Menu vs module improvements (split from patch thread)
« Reply #34 on: 21 / June / 2017, 16:58:13 »
Lua will also be a part of any installation type (save for Custom of course). As for uBASIC, I'm not sure there are too many people who are still using it.
Please, just stop with this business of letting people pick and choose modules.
Quote
SDM claims to be GPL, which is exactly the same as CHDK
It claims to be GPL, but what phil was referring to is that source for SDM releases is often not readily available.

For myself, I'd rather not spend my time worrying about licensing politics.
Don't forget what the H stands for.

Re: Menu vs module improvements (split from patch thread)
« Reply #35 on: 21 / June / 2017, 18:48:58 »
If you're going to get fussy about license agreements then you really shouldn't be supporting SDM at all.
SDM itself is a huge violation of the CHDK GPL license.

Phil.

Sorry to go off-topic, but I think I just arrived at Solomon's judgment:

The author of SDM has been asked to provide the sources according to the terms of its license. Since he has so far only provided the sources for SDM 2.1, that's the version CHIMP will be offering to install starting with 0.9.3 and until further notice.
Author of CHIMP, Canon Hack Installation and Management Platform

Re: Menu vs module improvements (split from patch thread)
« Reply #36 on: 22 / June / 2017, 20:47:12 »
Here's a working tool that will write modules metadata to _HDKMETA/PS/MODULES.JSN (source).
Author of CHIMP, Canon Hack Installation and Management Platform

 

Related Topics