new branch - CHDK : Elf Edition - Developers wanted - page 18 - General Discussion and Assistance

tsvstar

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #170 on: 04 / January / 2012, 10:23:00 »

Advertisements

Quote from: reyalp on 03 / January / 2012, 23:15:20

This raises a question: Do we need to have things like edge overlay be a module *and* compile time optional ? Some things still need to be optional because the platform might not support them, but for standalone modules, I don't see much reason.

I think best way for edgeovr is: move menu into module and hide correspondent item in the main menu if no such modules exists.

Logged

philmoz

3411

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #171 on: 04 / January / 2012, 17:37:47 »

Quote from: tsvstar on 04 / January / 2012, 10:23:00

Quote from: reyalp on 03 / January / 2012, 23:15:20
This raises a question: Do we need to have things like edge overlay be a module *and* compile time optional ? Some things still need to be optional because the platform might not support them, but for standalone modules, I don't see much reason.

I think best way for edgeovr is: move menu into module and hide correspondent item in the main menu if no such modules exists.

This would increase the CHDK code size though.

The compile time option is to allow the feature to be completely removed from the code - resulting in a smaller version of the CHDK core. Granted that moving most of the code to a module give you the bulk of the space saving there may still be value in keeping some of the compile options.

Putting the menu in the module also means the module has to be loaded when you access the CHDK menus - even if you haven't enabled edge overlay. Or you would need to change the menu system to be able to dynamicaly load a module menu when the menu option was selected. I'm not sure we need this level of sophistication just yet.

Phil.

Logged

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)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

tsvstar

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #172 on: 05 / January / 2012, 01:37:51 »

Hiding menu items part is already prepared for my different private project - gui rearrangement. In scope of this project I provide two mode: basic and advanced. First mode presume dynamic merging most of items of override menu (and so hide some of them) with keeping functionality, so override menu become more user-friendly.

Yes I meant dynamic load menu item. This is easy if whole submenu only could be separated to module: just add flag which mean that callback processor should be called. this callback run module. back button unload module. Pretty easy.

PS - I do agree with that saved by modules space are still valuable. And I do agree that this make more sophisticated with small benefits, althrough it very similar to modularity conception

Logged

tsvstar

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #173 on: 05 / January / 2012, 01:43:53 »

New very simple idea.
Remove system flag for edgeovr module and so it become visible in module list. When I choose this menu item (run module), it popup its internal submenu. Very flexible, very simple.
No dynamic hiding infrastructure required, no dynamic submenu load required. Just make possible save and restore current menu state to make more comfortable back navigation and nothing more.

Logged

philmoz

3411

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #174 on: 05 / January / 2012, 02:44:20 »

Quote from: tsvstar on 05 / January / 2012, 01:43:53

New very simple idea.
Remove system flag for edgeovr module and so it become visible in module list. When I choose this menu item (run module), it popup its internal submenu. Very flexible, very simple.
No dynamic hiding infrastructure required, no dynamic submenu load required. Just make possible save and restore current menu state to make more comfortable back navigation and nothing more.

The problem with this is it would remove the 'Edge Overlay' menu from it's current place in the main menu and be hidden away in the modules menu.

However combining this with the previous idea of having a new menu item type that refers to a module might work.
The existing 'Edge Overlay' menu points to the module, when selected the module loads to show it's menu and options. When the edge menu exits the system is already set up to pop back to the previous menu. If the edge overlay is enabled the module can be left loaded, otherwise it can be unloaded.

The same thing can be used to create static menu entries for all the interactive modules - restoring the Games menu for example.

This would also eliminate the need to open all the module files at startup - you are having problems with this and it has been reported as causing problems on the A460. It may be related to the file handling problems experienced when CHDK and the Canon firmware are opening and closing files at the same time. Until the problem is resolved a static menu system might cause less issues than the dynamic one.

Phil.

Logged

tsvstar

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #175 on: 05 / January / 2012, 04:40:54 »

Quote from: philmoz on 05 / January / 2012, 02:44:20

The problem with this is it would remove the 'Edge Overlay' menu from it's current place in the main menu and be hidden away in the modules menu.

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.
One big difference is that submenu items are unavailable to be mapped as UserMenu items. Just because this is separated from root hierarchy and probably not loaded menu.

Quote

The same thing can be used to create static menu entries for all the interactive modules - restoring the Games menu for example.

This would also eliminate the need to open all the module files at startup - you are having problems with this and it has been reported as causing problems on the A460. It may be related to the file handling problems experienced when CHDK and the Canon firmware are opening and closing files at the same time. Until the problem is resolved a static menu system might cause less issues than the dynamic one.

I do not like binding to modules static menu, because this cancel extensibility of modules. Now I could use new modules almost independent on version. Libraries (including edgeovr) could be exception just because they have strong dependencies with core.
I just propose simple way to remove discussed compile option and nothing more yet.

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.

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.

PS 3. Modules now are important part of system and many items are placed there. Probably this is good idea to move this item to the root menu.

Logged

philmoz

3411

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #176 on: 05 / January / 2012, 16:53:11 »

Quote from: tsvstar on 05 / January / 2012, 04:40:54

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.

Quote

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.

Quote

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.

Quote

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.

Logged

outslider

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #177 on: 05 / January / 2012, 18:01:59 »

Hey!

Forgive me, that I haven't answer about the memory browser. Now everything is ok.

Another bug (I'm not sure wheter it was mentioned before) - camera crashes when ALT menu is run too fast (after start, before LED stop blinking).

I'm attaching ROMLOG.

If there's no way to run menu so fast maybe disable MENU key in ALT mode or even entering ALT mode at all until CHDK is able to manage it?

ROMLOG.LOG (3.08 kB - downloaded 32 times.)

Logged

if (2*b || !2*b) {
cout<<question
}

Compile error: poor Yorick

philmoz

3411

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #178 on: 05 / January / 2012, 18:20:45 »

Quote from: outslider on 05 / January / 2012, 18:01:59

Hey!

Forgive me, that I haven't answer about the memory browser. Now everything is ok.

Another bug (I'm not sure wheter it was mentioned before) - camera crashes when ALT menu is run too fast (after start, before LED stop blinking).

I'm attaching ROMLOG.

If there's no way to run menu so fast maybe disable MENU key in ALT mode or even entering ALT mode at all until CHDK is able to manage it?

Which camera?

Is CAM_STARTUP_CRASH_FILE_OPEN_FIX defined in platform_camera.h for the camera?

The romlog error is the same one as described in this thread http://chdk.setepontos.com/index.php?topic=6179.0
The CAM_STARTUP_CRASH_FILE_OPEN_FIX option in platform_camera.h fixes this for all cases seen so far; but the module menu loading may be stressing things even more.

Phil.

Logged

outslider

Re: new branch - CHDK : Elf Edition - Developers wanted

« Reply #179 on: 05 / January / 2012, 18:54:17 »

Forgive me, I always post which camera do I have and this time I forgot.

SX130IS
Firmware 1.01c

I use CHDK trunk #1527

Yes, it's defined:
#define CAM_STARTUP_CRASH_FILE_OPEN_FIX 1

I don't remember, wheter not modular CHDK caused such crash, maybe I never noticed that. But now it's everytime I go to the menu too fast (CHDK teaches me patience now!).

EDIT

PS - I saw this thread: http://chdk.setepontos.com/index.php?topic=265.0 - should I post such things there rather? I don't like to make a mess in forum.

« Last Edit: 05 / January / 2012, 18:56:43 by outslider »

Logged

if (2*b || !2*b) {
cout<<question
}

Compile error: poor Yorick