[Scummvm-devel] GUI options/layout/etc

Eugene Sandulenko sev at scummvm.org
Thu Nov 24 20:45:51 CET 2011


On 24 November 2011 10:04, A. Milburn <fuzzie at users.sourceforge.net> wrote:
> A few ramblings about GUI options so they don't just get lost in the IRC
> logs. They're not complete but they *are* trying to be practical rather
> than ideal solutions which we might never get around to implementing
> (also I don't have much time this week, so if I said something really
> stupid, sorry!):
This is a really good thing that somebody is thinking about it and discussing.

> * I'd like to suggest just adding an 'Extras' tab for all the argued-over
>  enhancements. 'EGA undithering', 'mixed AdLib/MIDI mode', 'original
>  save/load dialogs', 'copy protection' and 'prefer synthesized effects'
Yes good point. Also we probably need to group/mark them per engine.

Also as discussed, since there are so many of them, it would be nice
to have a vertical scrolling on tabs implemented.

>  There's enough space for 6 checkboxes in there, more if we made the
>  labels shorter. I realise that there might be an argument about this
>  making the UI trickier on 320x200, but it doesn't seem that bad to me.
>  The only trouble would be that we don't have the space for single-game
>  options (like the alternative intros), but as far as I know no-one is
>  too bothered about those.
In fact they were planned for a long time, just no time to add them

> * The 'Output rate' combobox seems a bit pointless to have in the main
>  GUI. A lot of the backends override this themselves, and everything
>  except some of the SDL-based ones (not all) and the PSP backend
>  ignore the config setting.
In the modern world, yes. Especially in the light that majority of our
backends have this setting hardcoded. In the old times this setting
helped slow computers (sometimes).

>  We seem to default to 22khz on desktop platforms, something which dates
>  back in commit history to the first sound support. Can we not default
>  to 44khz on backends which can reasonably handle that and don't just
>  ignore the config anyway, and otherwise leave this as a fairly obscure
>  config option?
We need doublecheck that Adlib, MT32 and other emulators, particularly
Amiga ones in SCUMM engine behave correctly with 44kHz. They used to
have problems with it.

> * The 'Graphics mode' combobox seems a bit oddly used too - on various
>  backends it's empty because there's no choice of mode, the Dreamcast
>  backend provides one single mode, the PSP backend seems to use it to
>  provide 'keep aspect ratio' and 'full screen' options. Obviously it
>  *is* used on many backends though, so this is just an observation.
As we discussed, what we can do is to implement possibility to
completely hide certain widgets per backend. So provide a way for
backend to provide list of widget names to hide, and make the layout
engine to collapse space of these items.

> * Is the 'MT-32' tab necessary for backends which can't be connected
>  to real hardware but can run the emulators? Would it be possible to
>  just move the combobox to the 'MIDI' tab if the only options are
>  emulators for which we know whether they support GM/MT-32 natively,
>  or are those options important even with an emulator used?
No, and it is another per-backend feature.

> * In that vein, can't we rename the 'MIDI' tab to Music, plonk the
>  'AdLib emulator' option into it too, and then move the 'Volume'
>  tab into 'Audio' with the space left by removing two comboboxes,
>  at least on small-screen devices? Crazy? (I haven't tried it.)
>  But it would be less confusing to *me*, at least.
There is a distinction between digital music and MIDI. What about this one?

>  (Obviously if we could instead just have a single tab with the
>  audio device configuration that might be a much nicer way of doing
>  it, I just know that *I'm* not capable of making that work.)
Well.. In fact I split audio tab in the past because it did not fit
320x200 layout.

To recap my vision on the approach:

There are 2 tasks:
  o Removing widgets and providing per-backend content for popup widgets
  o Providing per-backend widgets

First part is resolved by introducing a OSystem method like
queryGUIConfig() which return XML or whatever consisting of list of
widget names to disable and content list with their IDs.

Second one is more complicated. Here is the proposed approach:

GUI consists of three parts:
  1. Layout described by XML
  2. Object creation implemented in C++
  3. Widget behaviour controlled by handleCommand() method

First thing to mention that to simplify things (at least in first
implementation) I propose to restrict backends' ability to add new
widgets to a single tab which will be represented on both global and
game options with relevant 'override' checkbox.

Part 1. Layout for the XML is provided by another OSystem call, or
even as part of above mentioned queryGUIConfig(). That is pretty
straightforward, albeit we are restricting Theme customisation (well,
there is no single customisation for new GUI code anyway, and old ones
did not touch our option tabs at all).

Part 2. Introduce new module to our backends, e.g. backends/gui, in
order to minimize dependency of backend code from GUI.
Let this code override OptionsDialog (and EditGameDialog?), which
particularly extend constructor (by adding additional tab),
reflowLayout() and handleCommand(). We already have that approach with
our EditGameDialog, so current code allows such approach.

Part 3. Is actually covered by 2.


Eugene




More information about the Scummvm-devel mailing list