[Scummvm-tracker] [ScummVM :: Bugs] #11637: GUI: STRETCH MODE: Popup Menu displays redundant 'Normal' setting.

[ScummVM :: Bugs]

#11637: GUI: STRETCH MODE: Popup Menu displays redundant 'Normal' setting.
---------------------+--------------------
  Reporter:  macca8  |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  low     |  Component:  GUI
Resolution:          |   Keywords:
      Game:          |
---------------------+--------------------
Description changed by macca8:

Old description:

> The Stretch Mode feature offers a choice of two popup menus, depending on
> whether or not the prevailing Graphics Mode supports the feature.
> If supported, the menu offers 4 or 5 specific settings (depending on the
> build), plus the standard Default.
> If unsupported, a single Normal setting is offered, plus the standard
> Default. If selected, this setting actually does nothing, other than
> write a ''stretch_mode=NONE'' entry in the config file, confirming the
> feature isn’t available.
>
> However, soon after the feature was added, a decision was made to hide
> the Stretch Mode option if not supported - effectively making the use of
> the Normal setting redundant.
> For example, this is the case with the 32-bit Intel Mac v2.1.2 release &
> current Daily builds, which contain a mix of non-OpenGL (unsupported) &
> OpenGL (supported) Graphics Modes.
>
> Presumably, if no Graphics Modes support the feature, it’s excluded from
> that  particular build, rather than hidden, but I’m unaware if that
> situation even exists.
>
> In theory, the Normal setting should never be seen, however, in practice,
> it’s still visible in two situations… an errant click by the user in the
> vicinity of the hidden popup menu (showing a detached menu for no visible
> Option), or, when revealing the Option by using the Apply button to
> switch to a compatible Graphics Mode (in this case, OpenGL). In the
> second case, the user must first return to the Launcher, then go back to
> the Graphics tab, to load the correct popup menu.
>
> So what to do? Making the feature permanently visible, regardless of
> support, would reinstate the original intention of using the Normal
> setting in an unsupported environment. However, this doesn’t resolve the
> issue of the incorrect menu displaying when switching to a compatible
> Graphics Mode.
>
> In my opinion, a better solution would be to remove the Normal setting
> from the code, since it’s already fallen out of favour as the preferred
> method for advising the feature is unavailable, then adapt the code to
> display only a single popup menu containing the 5 specific settings (plus
> Default).
>
> As for advising the user of the unavailability of the feature, I’d
> suggest making the Option visible, but disabled, for Graphics Modes that
> don’t support the feature.
>
> This alternative clearly conveys to the user that the greyed-out Option
> is unavailable, plus it makes the popup menu inaccessible (unlike the
> current situation where the hidden menu is still enabled). It also
> suggests that at least one of the Graphics Modes available in the build
> does actually support the feature. And with only a single popup menu
> available, there’s no conflict when switching to a compatible Graphics
> Mode.

New description:

 The Stretch Mode feature offers a choice of two popup menus, depending on
 whether or not the prevailing Graphics Mode supports the feature.
 If supported, the menu offers 4 or 5 specific settings (depending on the
 build), plus the standard Default.
 If unsupported, a single Normal setting is offered, plus the standard
 Default. If selected, this setting actually does nothing, other than write
 a ''stretch_mode=NONE'' entry in the config file, confirming the feature
 isn’t available.

 However, soon after the feature was added, a decision was made to hide the
 Stretch Mode option if not supported - effectively making the use of the
 Normal setting redundant.
 For example, this is the case with the 32-bit Intel Mac v2.1.2 release &
 current Daily builds, which contain a mix of non-OpenGL (unsupported) &
 OpenGL (supported) Graphics Modes.

 Presumably, if no Graphics Modes support the feature, it’s excluded from
 that  particular build, rather than hidden, but I’m unaware if that
 situation even exists.

 In theory, the Normal setting should never be seen, however, in practice,
 it’s still visible in two situations… an errant click by the user in the
 vicinity of the hidden popup menu (showing a detached menu for no visible
 Option), or, when revealing the Option by using the Apply button to switch
 to a compatible Graphics Mode (in this case, OpenGL). In the second case,
 the user must first return to the Launcher, then go back to the Graphics
 tab, to load the correct popup menu. See attached screenshots for examples
 of relevant behaviour.

 So what to do? Making the feature permanently visible, regardless of
 support, would reinstate the original intention of using the Normal
 setting in an unsupported environment. However, this doesn’t resolve the
 issue of the incorrect menu displaying when switching to a compatible
 Graphics Mode.

 In my opinion, a better solution would be to remove the Normal setting
 from the code, since it’s already fallen out of favour as the preferred
 method for advising the feature is unavailable, then adapt the code to
 display only a single popup menu containing the 5 specific settings (plus
 Default).

 As for advising the user of the unavailability of the feature, I’d suggest
 making the Option visible, but disabled, for Graphics Modes that don’t
 support the feature.

 This alternative clearly conveys to the user that the greyed-out Option is
 unavailable, plus it makes the popup menu inaccessible (unlike the current
 situation where the hidden menu is still enabled). It also suggests that
 at least one of the Graphics Modes available in the build does actually
 support the feature. And with only a single popup menu available, there’s
 no conflict when switching to a compatible Graphics Mode.

--
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/11637#comment:1>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM