1.5 development planning thread - page 5 - General Discussion and Assistance - CHDK Forum

1.5 development planning thread

  • 89 Replies
  • 46918 Views
Re: 1.5 development planning thread
« Reply #40 on: 27 / March / 2016, 12:01:43 »
Advertisements
Thanks, committed.
I'm not sure this is quite right yet.  Adding new strings breaks. Or there needs to be a new procedure documented?

If I apply the attached simple patch file to r4570 it works.  If I apply to r4571 then I get this :
Code: [Select]
../../../../lib/lang/lang_str.c -> lang_str.thm.o
In file included from ../../../../lib/lang/lang_str.c:10:0:
../../../../lib/lang/lang_str.h:957:2: error: #error The number of language string conditions does not match the number of language strings. Please update lib/lang/lang_str_conditions.h
 #error The number of language string conditions does not match the number of language strings. \
  ^
../../../makefile_sub.inc:26: recipe for target 'lang_str.thm.o' failed
make[1]: *** [lang_str.thm.o] Error 1
makefile_base.inc:103: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 4451
Re: 1.5 development planning thread
« Reply #41 on: 27 / March / 2016, 12:28:39 »
I'm not sure this is quite right yet.  Adding new strings breaks. Or there needs to be a new procedure documented?
When adding new strings, lib/lang/lang_str_conditions.h also needs to be updated with the new string IDs. The #error message does include this detail, but it might be a bit obscure. I guess we could add a note to core/gui_lang.h as a reminder, if you think it's needed.
Quote
#error The number of language string conditions does not match the number of language strings. Please update lib/lang/lang_str_conditions.h

Re: 1.5 development planning thread
« Reply #42 on: 27 / March / 2016, 12:55:10 »
When adding new strings, lib/lang/lang_str_conditions.h also needs to be updated with the new string IDs. The #error message does include this detail, but it might be a bit obscure. I guess we could add a note to core/gui_lang.h as a reminder, if you think it's needed.
Thanks - that fixed it.

I'm not sure the best place to document this.  Figuring out how to add a string and which files to modify has not exactly been obvious and we've just added another magic number file that needs to be updated.   

For reference, I believe the new procedure for adding a string is :
  • Add the new string to ../CHDK/LANG/english.lng . Strings are numbered sequentially so try looking for an empty slot to insert the string. If you can't find one (or you are adding multiple strings that you would like to group together),  add the string to the end of the file using the next free number(s).
  • Add any available language translations of the new string at the matching line in the  ../CHDK/LANG/XXX.lng file. CHDK will default to the english text for the string if the associated translation does not exist in any language file.
  • Create a new entry in ../core/gui_lang.h that #defines a new label (uppercase by convention) that references the number(s) you created in step 1.  Use this label in menus created in gui.c
  • Update the GUI_LANG_ITEMS value at the end of ../core/gui_lang.h if you added new entries.
  • Add a new blank entry to  ../lib/lang/lang_str_conditions.h with the same location and number used in step 1
  • If the new string may not be needed on some cameras, add the #defined conditional name instead of "" in step 5

Not sure if this exists on the wikia ? I'll take a look and if I don't find it I'll look for somewhere appropriate to add it.  Unless someone can point to where it already exists that is?  Maybe this could also go into gui_lang.h as well?

EDIT :
update per philmoz comment below and an additional note about GUI_LANG_ITEMS.
« Last Edit: 27 / March / 2016, 18:40:23 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.5 development planning thread
« Reply #43 on: 27 / March / 2016, 17:42:07 »
When adding new strings, lib/lang/lang_str_conditions.h also needs to be updated with the new string IDs. The #error message does include this detail, but it might be a bit obscure. I guess we could add a note to core/gui_lang.h as a reminder, if you think it's needed.
Thanks - that fixed it.

I'm not sure the best place to document this.  Figuring out how to add a string and which files to modify has not exactly been obvious and we've just added another magic number file that needs to be updated.   

For reference, I believe the new procedure for adding a string is :
  • Add the new string at the end of  ../CHDK/LANG/english.lng .  Pick the next sequential number to start the inserted line.
  • Add any available translations of the new string at the end of the appropriate  ../CHDK/LANG/XXX.lng file. CHDK will default to the english text for the string if the associated translation does not exist in any language file.
  • Create a new entry at the bottom of ../core/gui_lang.h that #defines a new label (uppercase by convention) that references the number you created in step 1.  Use this label in menus created in gui.c
  • Add a new blank entry at the bottom of ../lib/lang/lang_str_conditions.h with the same number used in step 1
  • If the new string may not be needed on some cameras, add the #defined conditional name instead of "" in step 4
Not sure if this exists on the wikia ? I'll take a look and if I don't find it I'll look for somewhere appropriate to add it.  Unless someone can point to where it already exists that is?  Maybe this could also go into gui_lang.h as well?


Hmm, hadn't considered that aspect. It does seem a but cumbersome.


Perhaps an alternative solution might be to add the conditional as a comment to 'gui_lang.h' and then parse that file in makelang.c (instead of including lang_str_conditions.h).


For example, in gui_lang.h:
Code: [Select]
#define LANG_MENU_MISC_FLASHLIGHT       72      //CONDITIONAL: CAM_SWIVEL_SCREEN


This removes the need for lang_str_conditions.h and keeps everything in one place, it also removes the error if a new string is added.


BTW: as part of step 1 I would suggest first looking for an empty slot instead of just adding to the end.
Currently unused numbers are - 89 252 254 351 381 399 400 412 413 414 420.


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

Re: 1.5 development planning thread
« Reply #44 on: 27 / March / 2016, 18:41:54 »
BTW: as part of step 1 I would suggest first looking for an empty slot instead of just adding to the end.
I edited the text in my previous post.  It's a bit awkward but anyone that deep in the code should be able to figure it out.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 4451
Re: 1.5 development planning thread
« Reply #45 on: 27 / March / 2016, 18:51:46 »
Hmm, hadn't considered that aspect. It does seem a but cumbersome.
Well, that's why I'm posting patches affecting core / build system here, for review. It's true that I went for a solution that was easy to implement.

Quote
Perhaps an alternative solution might be to add the conditional as a comment to 'gui_lang.h' and then parse that file in makelang.c (instead of including lang_str_conditions.h).


For example, in gui_lang.h:
Code: [Select]
#define LANG_MENU_MISC_FLASHLIGHT       72      //CONDITIONAL: CAM_SWIVEL_SCREEN


This removes the need for lang_str_conditions.h and keeps everything in one place,
That indeed looks better and easier to manage, but requires a lot more modifications in makelang.
Quote
BTW: as part of step 1 I would suggest first looking for an empty slot instead of just adding to the end.
Currently unused numbers are - 89 252 254 351 381 399 400 412 413 414 420.
For example, that's something that the current code (related to lang_str_conditions.h) can't detect (and warn with the deliberate #error).

Re: 1.5 development planning thread
« Reply #46 on: 27 / March / 2016, 19:02:41 »
It's true that I went for a solution that was easy to implement.
Works for me.  Just needed to understand the "rules".  It's not exactly something that gets changed every day.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.5 development planning thread
« Reply #47 on: 27 / March / 2016, 19:36:50 »
Hmm, hadn't considered that aspect. It does seem a bit cumbersome.
Well, that's why I'm posting patches affecting core / build system here, for review. It's true that I went for a solution that was easy to implement.


I wan't criticising your implementation - it's a good addition.
I hadn't thought through the implications to anyone wanting to add new strings - waterwingz description brought that into focus (no pun intended).


Here's a patch that moves the conditionals to gui_lang.h - I think I've got them all (with the correct negative logic).
Comments at the top of gui_lang.h should help anyone adding new strings.


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

*

Offline srsa_4c

  • ******
  • 4451
Re: 1.5 development planning thread
« Reply #48 on: 27 / March / 2016, 20:43:47 »
I wan't criticising your implementation - it's a good addition.
I hadn't thought through the implications to anyone wanting to add new strings - waterwingz description brought that into focus (no pun intended).
I have no problem with improvements (that also means it doesn't hurt my feelings if code written by me is replaced by something better).

In general, when I implement something, it can be expected that I go for an implementation that is easier for me to do.

Quote
Here's a patch that moves the conditionals to gui_lang.h - I think I've got them all (with the correct negative logic).
Comments at the top of gui_lang.h should help anyone adding new strings.
Will take a look soon (but I guess this should generate the same gui_lang_default string as the code in trunk - if so, you could just check it in).

edit: the generated lang_str.h is indeed the same (minus the #error at its end), so I'm OK with this change
« Last Edit: 27 / March / 2016, 21:24:18 by srsa_4c »

Re: 1.5 development planning thread
« Reply #49 on: 27 / March / 2016, 22:00:38 »
I wan't criticising your implementation - it's a good addition.
I hadn't thought through the implications to anyone wanting to add new strings - waterwingz description brought that into focus (no pun intended).
I have no problem with improvements (that also means it doesn't hurt my feelings if code written by me is replaced by something better).

In general, when I implement something, it can be expected that I go for an implementation that is easier for me to do.

Quote
Here's a patch that moves the conditionals to gui_lang.h - I think I've got them all (with the correct negative logic).
Comments at the top of gui_lang.h should help anyone adding new strings.
Will take a look soon (but I guess this should generate the same gui_lang_default string as the code in trunk - if so, you could just check it in).

edit: the generated lang_str.h is indeed the same (minus the #error at its end), so I'm OK with this change
Seeing as we have gone this far, there is almost certainly a way to write a script to parse a single suitably formatted string input file that spits out the necessary .c and .h files ?  Change the one input file,  all the required output files change.

I guess the question it how much that is worth?  srsa_4c's most recent patch is (maybe) not elegant but it works.  I'm good with that unless a single unifying script is a fun project someone wants to do?
Ported :   A1200    SD940   G10    Powershot N    G16

 

Related Topics


SimplePortal © 2008-2014, SimplePortal