supplierdeeply

1.4 development planning thread

  • 195 Replies
  • 27288 Views
Re: 1.4 development planning thread
« Reply #10 on: 19 / December / 2014, 19:39:47 »
Advertisements
In 1.4, do we need to keep the code that loads the old 1.2 CHDK config file if there is no 1.3 (or later) config file on the SD card?
It's not unusual for somebody to post here about an issue and we find out he is running a really old version of CHDK.  So in those rare cases, I guess it's nice if the config files migrate cleanly from his 0.9 to 1.4.   

However,  the question is how much that is worth?  I'd say "not a lot"  if it buys us something to abandon the old configs.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 11708
Re: 1.4 development planning thread
« Reply #11 on: 19 / December / 2014, 23:48:36 »
In 1.4, do we need to keep the code that loads the old 1.2 CHDK config file if there is no 1.3 (or later) config file on the SD card?
I think not. Someone jumping two versions probably shouldn't expect to keep their config.

Then again I was OK not automatically upgrading from 1.2 to 1.3 so I may not be the best one to ask ;)

If removing it affects set_config_value backward compatibility, that might be worth further discussion.

Script backward compatibility is also something I want to think about for 1.4, related to the discussion around http://chdk.setepontos.com/index.php?topic=2509.msg116416#msg116416

One thing that occurs to me is that the script param change would be a way to recognize old style and new style scripts.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 11708
Re: 1.4 development planning thread
« Reply #12 on: 20 / December / 2014, 01:02:25 »
On D10 using trunk 3830, I am unable to browse to a parent directory (..) in the file browser.  The stat column shows ???

I'm not sure if this is related to the long filename changes or the file browser re-write, but it happens whether or not long filenames are enabled so I'm guessing the former.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3071
    • Photos
Re: 1.4 development planning thread
« Reply #13 on: 20 / December / 2014, 01:49:17 »
On D10 using trunk 3830, I am unable to browse to a parent directory (..) in the file browser.  The stat column shows ???

I'm not sure if this is related to the long filename changes or the file browser re-write, but it happens whether or not long filenames are enabled so I'm guessing the former.

Can you try this patch please.

Looks like stat() fails when called with a path ending in '..' - the re-write was handling this slightly differently.

Since there isn't actually any point calling stat in this case, I've re-arranged the code to avoid it.

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

  • ******
  • 11708
Re: 1.4 development planning thread
« Reply #14 on: 20 / December / 2014, 02:22:39 »
Can you try this patch please.
That fixes it, thanks  :D
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 11708
Re: 1.4 development planning thread
« Reply #15 on: 21 / December / 2014, 18:47:25 »
Script compatibility discussion split to http://chdk.setepontos.com/index.php?topic=12138.0
Don't forget what the H stands for.

*

Offline msl

  • *****
  • 1251
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: 1.4 development planning thread
« Reply #16 on: 22 / December / 2014, 15:17:12 »
I'm not sure what you mean? Doing all these things at the same time, or because of the holidays?
Both. It is quite difficult to follow all of this things for tests and documentation on these days. On holidays should be more time for family and friends. ;)

msl
CHDK-DE:  CHDK-DE links

*

Offline reyalp

  • ******
  • 11708
Re: 1.4 development planning thread
« Reply #17 on: 22 / December / 2014, 16:10:30 »
It is quite difficult to follow all of this things for tests and documentation on these days. On holidays should be more time for family and friends. ;)
I understand what you mean, but for some of us (including me) it's when we have more time for hobbies.

I'm not too worried about everything going into the trunk be tested and fully documented yet. My original reason to want an "unstable" branch was to allow for experiments and features that time to be properly worked out. In 1.3 we kept it pretty stable through development, but for 1.4 I'm happy to have it be a bit more aggressive. In a few months or so I expect to switch to a stabilization phase where we stop adding major features. I may regret this approach later ;)

This means that users really should stick with 1.3 for now unless they want to be on the bleeding edge.
Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 11708
Re: 1.4 development planning thread
« Reply #18 on: 01 / January / 2015, 15:02:31 »
edit: thread http://chdk.setepontos.com/index.php?topic=12163.0

Modemap cleanup:
1) Deal with the "video recording while in still" +1024 values.
2) Remove the SCN_ * vs non SCN_ versions
3) Remove bogus TX1 entries
#1 can likely also be used to reliably detect video recording on some cameras.

Ref
http://chdk.setepontos.com/index.php?topic=7127.msg119554#msg119554
and original mode switching thread
http://chdk.setepontos.com/index.php?topic=3228.msg43452#msg43452
« Last Edit: 01 / January / 2015, 17:22:24 by reyalp »
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3786
Re: 1.4 development planning thread
« Reply #19 on: 02 / January / 2015, 17:05:36 »
* srsa' digic 6 support and ports
It's perhaps time for me to start asking questions about this one. I'm not sure what's the best place to do it, so I'm starting here.

First, my main concerns now are:
- putting DIGIC 6 support code in trunk would make backports of bugfixes/enhancements even more difficult due to the number of changes
- there's already a huge amount of new features in current trunk, waiting to be tested/stabilized
- once DIGIC 6 support is in, every change in UI (etc.) will need to take the new display resolutions (, framebuffer formats, CPU) into account

Currently, I'm not even trying to keep my DIGIC 6 "fork" up-to-date, because
- resolving conflicts would take a considerable amount of time
- I'm using lots of "hacks" which I think should be done differently, keeping these updated seems like wasted time to me

What do you guys think would be the best approach for integration?

edit: link added
« Last Edit: 02 / January / 2015, 17:07:49 by srsa_4c »

 

Related Topics