supplierdeeply

1.3 development planning thread

  • 43 Replies
  • 4652 Views
*

Offline reyalp

  • ******
  • 10068
1.3 development planning thread
« on: 31 / July / 2013, 01:11:49 »
Advertisements
Here's a thread to discuss what we want to do in 1.3

A few items on my list

* Further cleanup in the ISO override code: http://chdk.setepontos.com/index.php?topic=10341.msg103289#msg103289
* Organization / build changes to allow supporting Digic 6 / thumb2 cameras
* Lua library to access to conf settings by name (split conf defines into an include, generate table like propcase and modemap) http://chdk.setepontos.com/index.php?topic=9602.msg98965#msg98965
* Standard libraries or functions to convert between APEX96 and traditional units.
* Allow PTP to cleanly kill running script
* Make convert_dng_to_chdk_raw smarter about it's buffer size
* Make PTP not always 50% of available RAM for buffer http://chdk.setepontos.com/index.php?topic=4338.msg103076#msg103076
* Rework key handling to allow sending keypresses to CHDK (especially useful for ptp control)
* Rework script LED to code to allow portable values
* Expose flash ready properly to script
* edit to add - reyalp should lern to spel gud.
« Last Edit: 31 / July / 2013, 23:13:45 by reyalp »
Don't forget what the H stands for.

Re: 1.3 development planning thred
« Reply #1 on: 31 / July / 2013, 19:19:04 »
A couple of things I've been thinking about - most have been discussed before.

1) User customizability : 
 - CCHDK2.CFG broken out so that OSD setup is stored seperately
 - allow the person doing the port to specifiy the default OSD layout for that port

2) Scripting Enhancements
 - allow scripts to be activated from the User Menu (in addition to script loading currently supported)
 - allow certain events to launch a unique script ( power up, Scene mode selected, shooting, shortcut button pressed ..)
 

*

Offline philmoz

  • *****
  • 2936
    • Photos
Re: 1.3 development planning thred
« Reply #2 on: 31 / July / 2013, 19:26:41 »
1) User customizability : 
 - CCHDK2.CFG broken out so that OSD setup is stored seperately

When I suggested this in April the consensus seemed to be it was not worth doing?
http://chdk.setepontos.com/index.php?topic=9602.0

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: 1.3 development planning thred
« Reply #3 on: 31 / July / 2013, 19:33:10 »
When I suggested this in April the consensus seemed to be it was not worth doing?
http://chdk.setepontos.com/index.php?topic=9602.0
You did.

And I responded to that one essentially saying that saving the OSD settings separately interested me.  I wasn't so sure about the benefits of splitting other things out but I was & am not against it.


*

Offline lapser

  • *****
  • 1022
  • SX50_100b / SX260_101a / G1X_100g / D20_100b
Re: 1.3 development planning thred
« Reply #4 on: 31 / July / 2013, 20:31:47 »
* Standard libraries or functions to convert between APEX96 and traditional units.
I have this working in my mods. I need to make sure I'm using the right constant in the iso_to_sv96() function, and write a test script and docs. I'll post a diff of just these functions and reyalp can take it from there.

I got my time lapse mods to work with the new 1.3 branch. I noticed you changed "kbd.c" to "kbd_process.c".

CHDK shell goes automatically to the 1.3 branch now.

*

Offline philmoz

  • *****
  • 2936
    • Photos
Re: 1.3 development planning thred
« Reply #5 on: 31 / July / 2013, 20:43:37 »
I got my time lapse mods to work with the new 1.3 branch. I noticed you changed "kbd.c" to "kbd_process.c".

This was done to avoid a name conflict with kbd.c in the platform/sub directory.
The platform dependant source files from 'core' are now compiled to object files in platform/sub - this avoids having to do a make clean when switching cameras.

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)

*

Offline reyalp

  • ******
  • 10068
Re: 1.3 development planning thred
« Reply #6 on: 31 / July / 2013, 23:13:24 »
1) User customizability : 
 - CCHDK2.CFG broken out so that OSD setup is stored seperately

When I suggested this in April the consensus seemed to be it was not worth doing?
http://chdk.setepontos.com/index.php?topic=9602.0

Phil.
My fear with breaking it up is that instead of 1 cfg that occasionally becomes incompatible and has to be deleted, we will have a bunch. So when users have problems it will just be "delete *.cfg" instead of "delete the cfg" which doesn't really help anything.

3 files as proposed in phils final post might be a good compromise, I'm not totally against it.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 2936
    • Photos
Re: 1.3 development planning thred
« Reply #7 on: 01 / August / 2013, 08:48:51 »
When I suggested this in April the consensus seemed to be it was not worth doing?
http://chdk.setepontos.com/index.php?topic=9602.0
You did.

And I responded to that one essentially saying that saving the OSD settings separately interested me.  I wasn't so sure about the benefits of splitting other things out but I was & am not against it.

Will mean changing the file name  - CCHDK4.CFG.
Are you sure you want to go through that again?

Saving the user menu settings is to a new file is fairly easy.

The OSD settings is a bit trickier - we will need to have some agreement on what constitutes an OSD setting.
For example are the battery min/max voltage values OSD settings?

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: 1.3 development planning thred
« Reply #8 on: 01 / August / 2013, 13:20:59 »
My fear with breaking it up is that instead of 1 cfg that occasionally becomes incompatible and has to be deleted, we will have a bunch. So when users have problems it will just be "delete *.cfg" instead of "delete the cfg" which doesn't really help anything.  3 files as proposed in phils final post might be a good compromise, I'm not totally against it.
What about a CHDK/CCHDK subdirectory?  Then the instructions to delete are "delete everything in the CHDK/CCHDK directory.

Will mean changing the file name  - CCHDK4.CFG.  Are you sure you want to go through that again?
It felt relatively painless to me.  In fact,  it was handy when I needed to revert back to 1.1.0 to answer a particular question on the forum.

Quote
For example are the battery min/max voltage values OSD settings?
Yes ?

*

Offline reyalp

  • ******
  • 10068
Re: 1.3 development planning thred
« Reply #9 on: 01 / August / 2013, 15:49:15 »
What about a CHDK/CCHDK subdirectory?  Then the instructions to delete are "delete everything in the CHDK/CCHDK directory.
I didn't mean the imply that deleting *.cfg was a problem. Rather the point is that having the CFG split up doesn't really help if the default response is to delete all of them, if anything it makes it more complicated. If the cfgs are split up, the we have to have a version in the name of each one when make incompatible changes.
Don't forget what the H stands for.

 

Related Topics