variable file select window sizes ?

waterwingz

11891

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?

fselect.patch (4.07 kB - downloaded 13 times.)

« Last Edit: 27 / September / 2014, 12:18:25 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3107

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.

Logged

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)

srsa_4c

3920

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.

Logged

Menu jumping/flickering on M10?

waterwingz

11891

Re: variable file select window sizes ?

« Reply #3 on: 27 / September / 2014, 18:20:45 »

Quote from: srsa_4c 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.

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.

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3107

Re: variable file select window sizes ?

« Reply #4 on: 27 / September / 2014, 18:24:54 »

Quote from: waterwingz on 27 / September / 2014, 18:20:45

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.

Logged

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)

srsa_4c

3920

Re: variable file select window sizes ?

« Reply #5 on: 27 / September / 2014, 18:40:07 »

Quote from: waterwingz on 27 / September / 2014, 18:20:45

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.

Logged

Menu jumping/flickering on M10?

waterwingz

11891

Re: variable file select window sizes ?

« Reply #6 on: 27 / September / 2014, 18:50:16 »

Quote from: srsa_4c on 27 / September / 2014, 18:40:07

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."

Logged

Ported : A1200 SD940 G10 Powershot N G16

srsa_4c

3920

Re: variable file select window sizes ?

« Reply #7 on: 27 / September / 2014, 19:19:00 »

Quote from: waterwingz on 27 / September / 2014, 18:50:16

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.

Logged

Menu jumping/flickering on M10?

waterwingz

11891

Re: variable file select window sizes ?

« Reply #8 on: 27 / September / 2014, 19:49:25 »

Quote from: srsa_4c on 27 / September / 2014, 19:19:00

Quote from: waterwingz on 27 / September / 2014, 18:50:16
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.

Logged

Ported : A1200 SD940 G10 Powershot N G16