[Scummvm-devel] Global menu save/load dialogs

John Willis John.Willis at Distant-earth.com
Mon Nov 10 20:28:39 CET 2008

>> True, though as I mentioned I fail to see why this feature should  
>> be kept
>> optional (apart from the sentimental value of the original dialogs, I
>> suppose), since it's clearly an enhancement over the original ones.
> I actually agree with Travis here. We should keep the original  
> dialogs as
> default, means F5 or the key/button matching for the original engine,
> should always display the original dialog.

>I agree with your agreement ;). That is: I want the GMM to be  
>accessible in all engines, but I do not wish to force this upon users.  
>So, users can continue to use the game's GUI, if any, but if they want  
>to, they can take advantage of the GMM.

Just to fan the flames a little why does it seem the idea of determining
this at runtime has been discounted? (Hint: I may have missed this, playing
catch-up after a busy few weeks and not got to the Wiki yet let alone

With all the work on the menu, configuration and the like could an option
such as "Use unified save/load menus" not just be snuck into the options
dialog? Ok, there is a little evaluation that has to happen at runtime but
this could be minimised. Just default it to 'off'. Maybe do this in addition
to a new key combo but that starts to look all a little bloated I guess.

>Also, it should be possible for *backends* to trigger the GMM, e.g. by  
>adding a new event for that. This way, we can add a "open GMM" hotkey  
>to console ports with few keys. That might be quite useful.

This would be more then useful :). IMHO some of the ports would gain more
from a standard load/save dialog system (with things like known visual
constraints) then they would loose not seeing the original dialogues. A
standard event for this that dropped back to the engines 'original' save
dialogues if the GMM was not suitable would be an ideal situation ;). Keep
what we have by all means but give porters the flexibility to force the GMM
if it suits there environment better.

Just my 2p,


More information about the Scummvm-devel mailing list