variable file select window sizes ? - General Discussion and Assistance - CHDK Forum

variable file select window sizes ?

  • 8 Replies
  • 7622 Views
variable file select window sizes ?
« on: 27 / September / 2014, 12:13:15 »
Advertisements
The Powershot N has limited screen space when the onscreen touch menu navigation buttons are active.   With a little care, this has not been a problem except for the file select window (from modules/gui_fselect.c).  It's just too wide for the buttons it needs to use with the current N UI spacing.

Attached is a candidate patch file that provides a narrower file select window on a per camera basis (platform_camera.h option).   It allows column widths to be truncated. For exampe,  the N will have a date/time column width that only shows the date and it uses a narrower file name column as the 8.3 convention did not need all the available width.   But there are no doubt a few other implementation issues that could use some comments. 

In particular, the new option in platform_camera.h simply selects narrow or wide mode(default).  The actual column widths are hard coded in camera.h (previously they were hard coded in gui_fselect.c).  Is it worth adding three column width options to platform_camera.h so that they are completely configurable rather than just narrow or wide?  (the code in gui_fselect.c seems to be okay with 0 size as a column width choice).

Comments?  Is there a better way to get this done?
« Last Edit: 27 / September / 2014, 12:18:25 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: variable file select window sizes ?
« Reply #1 on: 27 / September / 2014, 17:52:54 »
Looks ok to me.

If you want to allow complete override of the column widths, you don't need four #defines - you can include it all in a single value.

In camera.h
Code: [Select]
    #define CAM_GUI_FSELECT_SIZE 15, 7, 14
and in camera_info.c
Code: [Select]
    CAM_MENU_BORDERWIDTH,
    CAM_GUI_FSELECT_SIZE,

You can then override CAM_GUI_FSELECT_SIZE in the N platform_camera.h.

An alternative might be to use the existing camera_info.ts_button_border value to calculate the sizes dynamically in gui_fselect_init. This might get messy though.

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: variable file select window sizes ?
« Reply #2 on: 27 / September / 2014, 17:59:29 »
I would consider a different approach: The dialog itself could decide on which elements (columns) to draw - based on available screen space. So, instead of introducing file selector specific members to _cam_screen, we could add members which specify the space occupied by the buttons.

edit: this information may already be there based on what Phil says.

Re: variable file select window sizes ?
« Reply #3 on: 27 / September / 2014, 18:20:45 »
I would consider a different approach: The dialog itself could decide on which elements (columns) to draw - based on available screen space. So, instead of introducing file selector specific members to _cam_screen, we could add members which specify the space occupied by the buttons.
Thanks for the comment.  I think that if I was writing the fselect stuff from scratch then your approach would make a lot of sense.  But I'm looking for one of those "minimal change" things.

FWIW - the patch does not remove any of the existing columns,  it just makes some of them narrower.  I guess that it could be triggered to evaluate screen space stuff on the fly in gui_fselect.c as suggested.  But it's one of those things that doesn't really need to be calculated on the fly - it will be a fixed value for any build.  And I suspect it will be easier to let the person doing the port pick the column widths rather than try to write code that can "guess" the best looking layout on the fly.

Also, those button definitions are still kind of a loose part of an early CHDK Touch GUI based on two ports by two people that are not laid out completely the same way.

I think that I'll submit an updated patch based on philmoz's suggestion about putting all three column widths in one #define.

Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: variable file select window sizes ?
« Reply #4 on: 27 / September / 2014, 18:24:54 »
Also, those button definitions are still kind of a loose part of an early CHDK Touch GUI based on two ports by two people that are not laid out completely the same way.

I think that I'll submit an updated patch based on philmoz's suggestion about putting all three column widths in one #define.

Sounds good.

Ideal approach would be a full touch GUI (and eliminate or reduce the touch buttons); but that would be a lot of work for a handful of 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)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4451
Re: variable file select window sizes ?
« Reply #5 on: 27 / September / 2014, 18:40:07 »
Thanks for the comment.  I think that if I was writing the fselect stuff from scratch then your approach would make a lot of sense.  But I'm looking for one of those "minimal change" things.
I see.
My concern is that - currently - DIGIC 6 cameras have (at least) 640x480 pixels of screen space and many parts of the CHDK GUI are unaware of that. Additionally, if we'd ever like to support displays other than the LCD, a more scalable GUI would be desirable.


Re: variable file select window sizes ?
« Reply #6 on: 27 / September / 2014, 18:50:16 »
My concern is that - currently - DIGIC 6 cameras have (at least) 640x480 pixels of screen space and many parts of the CHDK GUI are unaware of that. Additionally, if we'd ever like to support displays other than the LCD, a more scalable GUI would be desirable.
We are perhaps starting to stray into a CHDK GUI 3.0 conversation?   

As I think I tried to suggest during the GUI 2.0 conversation,  most of the CHDK GUI is a just big menu for setting up and configuring CHDK.  Not a lot of effort has gone into CHDK's actual use while engaging in photography.  CHDKplus.lua is one simple example of the kinds of things that could be done.  A better User Menu (one that lets you launch rather than just load scripts for example) is another.  Just making more use of the empty <ALT> screen through a button panel might be another good change.

"So many ideas - so little time."
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 4451
Re: variable file select window sizes ?
« Reply #7 on: 27 / September / 2014, 19:19:00 »
We are perhaps starting to stray into a CHDK GUI 3.0 conversation?
Looks like it.
Anyway, I think the GUI should not change much for 1.3 - this usability modification is needed for your port of course.
I'd like to not sweat blood when merging all those little changes I currently have in my sx280 port. That merge will only happen after 1.3, but it needs to be considered.

Re: variable file select window sizes ?
« Reply #8 on: 27 / September / 2014, 19:49:25 »
We are perhaps starting to stray into a CHDK GUI 3.0 conversation?
Looks like it.
Anyway, I think the GUI should not change much for 1.3 - this usability modification is needed for your port of course.
I'd like to not sweat blood when merging all those little changes I currently have in my sx280 port. That merge will only happen after 1.3, but it needs to be considered.
We must be getting close to a "code freeze" of some sort.  I think even msl's suggested changes to script return values & names could wait for 1.4.0.   It would be easier to manage that way too I think.
Ported :   A1200    SD940   G10    Powershot N    G16

 

Related Topics


SimplePortal © 2008-2014, SimplePortal