[Scummvm-devel] SaveLoadChooser.PageDisplay vs lowres themes

Johannes Schickel lordhoto at gmail.com
Sat Jan 11 17:47:52 CET 2014

On 01/11/2014 05:41 PM, Marcus Comstedt wrote:
> Johannes Schickel <lordhoto at gmail.com> writes:
>> Hm, that explains why it might explode. The lowres layout doesn't have
>> any page wigdet, this var to check whether they are available is really
>> only a hack. So, if you want to use the lowres layout for higher
>> resolutions you will probably have to patch those theme files and/or
>> possibly delay the page display widget generation in the grid based chooser.
>>> However, if I revert that change and use -g1x as you suggest, I still
>>> can reproduce the issue.
>> Did you make sure to recompile (and regenerate the builtin theme)
>> ScummVM after reverting the change in classic_layout_lowres.stx?
> Hm, somehow I must have rebuilt things in the wrong order, because I
> got a scenario where the window size would switch to 2x when the game
> started (because the graphics mode was set to "default" in the
> options), but the theme stayed in lowres mode, so I figured that was
> the normal behaviour, but now after another rebuild that doesn't
> happen anymore.
> So I guess if you don't fiddle around with the resolution attributes
> (which I did because I wanted to fix the spacing in the lowres menu
>   without having to test-run on the Dreamcast :) there's no real
> problem.
> However, it seems that there are two separate checks on resolution
> 1) Which stx file to use (by resolution attribute)
> 2) Grid chooser or not (test elsewhere?)
> while there is also a requirement that these tests make the same
> decision about what is "low" resolution.
> This seems like poor design; shouldn't there be _one_ test, controling
> (directly or indirectly) both which XML to use, and whether or not to
> use the gridlayout?
> It seems to me that having a
> 		<def var = 'AllowGridChooser' value = '0'/>
> rather than
> 		<def var = 'ShowChooserPageDisplay' value = '0'/>
> would both solve this issue, and remove the need for the "hack"...

The hack would still be required, because of the implementation of the 
choosers. It's two different classes, so it will try to reflow the grid 
choser when it's open anyway (because that one is on top of the dialog 
stack and thus reflowLayout will be called). It's a pretty hacky way to 
allow two different choosers to be there right now... It's still 
somewhat nicer than having the code for both in one class. We could 
however get rid of the resolution check for the grid based one in 
getRequestedSaveLoadDialog with using the variable there too, yes.

// Johannes

More information about the Scummvm-devel mailing list