CHDK UI version 2.0 ? - page 6 - General Discussion and Assistance - CHDK Forum

CHDK UI version 2.0 ?

  • 542 Replies
  • 140784 Views
*

Offline reyalp

  • ******
  • 14098
Re: CHDK UI version 2.0 ?
« Reply #50 on: 02 / June / 2012, 17:26:40 »
Advertisements
]That works as you describe.   What happens when you load a different script ?  Does it store all 10 sets of parameter settings for each script ?
Yes. Look in CHDK/DATA

Note these will get confused if you have lua and ubasic scripts with the same basename. Long file names may be an issue on some cameras too.
Don't forget what the H stands for.

Re: CHDK UI version 2.0 ?
« Reply #51 on: 02 / June / 2012, 19:05:48 »
Yes. Look in CHDK/DATA
Note these will get confused if you have lua and ubasic scripts with the same basename. Long file names may be an issue on some cameras too.
Thanks - I see that now. I suppose I could have just looked at the code but I was feeling lazy today.

So maybe in the User Menu example I gave above should also let you specify the parameter set to use  (0=none).  Not sure how to do that so it makes any sense - you'd just need to know what you put in each parameter set you want to use I guess.
Ported :   A1200    SD940   G10    Powershot N    G16

Re: CHDK UI version 2.0 ?
« Reply #52 on: 03 / June / 2012, 05:57:39 »
The parameters set could have their names, which user could set by textbox. But this would be even more compicated... What about my modification of waterwingz's script menu? When it shows list of scripts and left button shows the parameter menu for each script?

I believe that good idea would be to not allow to run script from the any directory on SD but only from SCRIPTS (or its subdirs maybe). Then the "Load script from file" would be useless and script menu could only contain set of scripts in SCRIPTS dir. Less confusing, no problems with scripts sharing the same name in different dirs.
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: CHDK UI version 2.0 ?
« Reply #53 on: 03 / June / 2012, 07:34:19 »
I like philmoz's ALT mode shortcut display. I think it is however missing the most important shortcuts (script start, chdk menu, script menu, exit alt). In addition to what was proposed before, this display could also auto hide after a configurable delay (maybe someone suggested that already, I may have missed it).

I agree with reyalp that ALT-SHOOT script start is probably one of the biggest problems beginners have, but I would also expect that a big ALT mode shortcut help screen on the display would effectively change that. On the other hand it could be more intuitive if scripts only started in script menu: ALT-MODE-SHOOT wouldn't be much slower than ALT-SHOOT.

Would full shutter press anywhere else in alt mode then exit alt and press shoot_half + shoot_full?.


I kind of hate icon interfaces, at least on devices and features I don't use daily, mostly because it takes time to learn to associate a new icon with a feature and because many features just aren't well described with a small low resolution image. I believe one of the biggest reason for choosing an icon interface is that it makes localization unnecessary. It may also suit a vertical screen better for users with poor eyesight.


As for script parameters, scripts really should have a way to push enumerated lists and tooltip help messages into the script params menu as things like 
Code: [Select]
@param i Masking (0=No 1=Mask 2=Use)
@default i 0
are a bit silly and often quite difficult to understand due to length limitation of @param description (example is from MDFB).


Re: CHDK UI version 2.0 ?
« Reply #54 on: 03 / June / 2012, 08:48:10 »
As for script parameters, scripts really should have a way to push enumerated lists and tooltip help messages into the script params menu as things like 
Code: [Select]
@param i Masking (0=No 1=Mask 2=Use)
@default i 0
are a bit silly and often quite difficult to understand due to length limitation of @param description (example is from MDFB).


IMO it is TODO number one. To not break the compatibility with existing scripts there could be folowing syntax:

Code: [Select]

@param x value
@default x 0

@enumparam c ("blabla","no","foo") what to to?
@default c "foo"

so the parser would check whether the line is @param (behave as now) or @enumparam - then first char is an variable name, second, between () is a table and all the rest is a description. Variable c is set to the string chosen by user.

If any effort will be done here it is worth to change one-char variables to words.

When in the source there is the @param parser? I would like to play with that a little.
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: CHDK UI version 2.0 ?
« Reply #55 on: 03 / June / 2012, 09:20:06 »
When in the source there is the @param parser? I would like to play with that a little.

In beginning of core/script.c, static int process_param.

Re: CHDK UI version 2.0 ?
« Reply #56 on: 03 / June / 2012, 10:21:55 »
I agree with reyalp that ALT-SHOOT script start is probably one of the biggest problems beginners have, but I would also expect that a big ALT mode shortcut help screen on the display would effectively change that. On the other hand it could be more intuitive if scripts only started in script menu: ALT-MODE-SHOOT wouldn't be much slower than ALT-SHOOT.
I believe there was a strong desire expressed to leave the <ALT> mode entry screen clear so that you can use the LCD to correctly frame your shot and pick the correct time to launch a shooting script.  This would hinder that I'm afraid.

Note these will get confused if you have lua and ubasic scripts with the same basename.
Might be worth a little effort to have seperate subdirs for Lua and uBASIC then ?
« Last Edit: 03 / June / 2012, 11:10:37 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

Re: CHDK UI version 2.0 ?
« Reply #57 on: 03 / June / 2012, 11:08:58 »
What about my modification of waterwingz's script menu? When it shows list of scripts and left button shows the parameter menu for each script?
I like that one a lot. A proper Script Menu and an improved User Menu will be two different coding projects but they should share common code and work the same way.

Quote
I believe that good idea would be to not allow to run script from the any directory on SD but only from SCRIPTS (or its subdirs maybe).
I don't see any problem here - the script parameters are all stored in a common subdirectory already (as reyalp pointed out).  Subdirs might be problematic as many cams have path length limits (around 32 chars IIRC).

Quote
Then the "Load script from file" would be useless and script menu could only contain set of scripts in SCRIPTS dir.
Even better if the menu takes the name from the @title inside the script and only used the file name if there is no title.

Quote
Less confusing, no problems with scripts sharing the same name in different dirs.
Or maybe that's a drawback - filenames need to be unique if we use a common directory?
Ported :   A1200    SD940   G10    Powershot N    G16


Re: CHDK UI version 2.0 ?
« Reply #58 on: 03 / June / 2012, 15:16:46 »
Reading the script.c code I understand, why nobody likes to change the params to have longer names... They are stored in table numerated by letter, 1 for a, 2 for b...

Seems like to change anything the whole code has to be rewritten as well as (I believe) part of scripts menu, which probably uses the returned values... Ugh!


For me it could be easier to add enumerated lists as the first thing. I think that to start this process there need to be folowing changes:

* script_params_type[] table has to be added, it would contain the type of the parameter.
* in static void script_scan the check for @enumparam has to be added
* above should call process_enumparam which would break the param line string into a 2d table (number of the param and its value)
* before gui.c produces script submenu it should check what is the param type in script_params_type[] for given param and display MENUITEM_INT or MENUITEM_ENUM with values from table

This is only a draft, a lot of coding... Who wanna play?

I don't know where the params are posted to the script interpreter so the values are available.
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

*

Offline reyalp

  • ******
  • 14098
Re: CHDK UI version 2.0 ?
« Reply #59 on: 03 / June / 2012, 16:36:53 »
Reading the script.c code I understand, why nobody likes to change the params to have longer names... They are stored in table numerated by letter, 1 for a, 2 for b...
ubasic only permits one letter variables no matter what.

All that code is a pretty big mess. If it gets re-written, I'd like to see it become less of a mess.

Rather than extending the options screen, it might be better to come up with a way for scripts draw their own options screen. I'm thinking the script would be run with a special parameter, or a particular function would be run when the menu was accessed. It might be necessary to separate script selection from script configuration. The script would be given some primitives to draw things like enum values, numeric fields, text etc (mostly exist in drawings already). This would be fairly easy to do in lua, less so for ubasic. I'd personally be OK with require such scripts be in lua.
On the other hand it could be more intuitive if scripts only started in script menu: ALT-MODE-SHOOT wouldn't be much slower than ALT-SHOOT.
If we go this way, one option would be to use the func button. Currently it only opens the script menu. Instead, it could go to script mode. If you have a script selected, you are ready to shoot and pressing menu will bring up the script dialog. If you don't have a script selected, it would bring up the script dialog.
Quote
Would full shutter press anywhere else in alt mode then exit alt and press shoot_half + shoot_full?.
That's a good question. Another question would be what the other keys would do in script mode. For example, you could have left/right switch between option sets.
Quote
I kind of hate icon interfaces, at least on devices and features I don't use daily, mostly because it takes time to learn to associate a new icon with a feature and because many features just aren't well described with a small low resolution image.
Agreed.
Don't forget what the H stands for.

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal