[Scummvm-devel] RTL branch to be merged (relevant for *all* developers)

[Max Horn]

Am 02.09.2008 um 10:00 schrieb Johannes Schickel:

> On Tuesday 02 September 2008 09:21:02 Filippos K wrote:
>>> And now, opinion's corner: speaking of general behaviour, after an  
>>> engine
>>> is shutdown it should
>>> always go back to the launcher. The only way for a direct quit  
>>> should be
>>> the GMM dialog. What do
>>> you guys think about this?
>>
>> I agree on this, I believe it would be better if engines always  
>> return to
>> launcher...
>
> I'm against it actually. Most engines which feature the original  
> menu actually
> ask the user to *quit* the game and I would find it most confusing  
> if I'm
> still running ScummVM when I asked to *quit* the application.

I fully agree with Johannes here: If I press "Quit" in a game, I mean  
it. I don't want to return to the launcher then. If I want that, then  
I either have to use the GMM (or some other port specific means, e.g.  
the "Start" button on some controllers might be appropriate -- or not,  
just an example). Also, of course engines are free to augment existing  
dialogs to offer "RTL" besides offering "Quit"; but of course for most  
that will be hard or impossible, given that those in-game GUI features  
are usually rendered with image data fro the game's data files.


>> As for the engine features: I think that currently, most engines  
>> support
>> these (i.e. return to launcher, list saves etc), with some notable
>> exceptions where save games are completely handled by scripts.  
>> Wouldn't it
>> be better semantically to change these features the other way  
>> around, i.e.
>> mark engines that do NOT support them? (e.g. kSupportsRTL 		->
>> kDoesNotSupportRTL and so on)
>
> I think that it supports RTL is something special not every engine  
> (think of
> future engines) may be able to support, thus an indication flag that  
> it
> supports it makes much more sense to me than a flag that it does not  
> support
> it.

Indeed. I want the flags to stay the way mainly for two reasons:

1) Negated statements are harder to understand and easier to mix up:  
"If the kDoesNotSupportRTL flag is not set, then RTL *is* supported"  
is more complicated than "if kSupportsRTL is set, RTL *is* supported".  
Granted, this example sounds trivial, but once you have to parse in  
your mind complex code expressions based on checking this flag, you'll  
start to notice the difference.

2) An engine has to *explicitly* implement support for these features.  
Hence, it is natural that it has to *explicitly* advertise that  
feature. This way, the "default" option for the engine author (namely  
not to do anything about engine meta flags, maybe not even knowing  
about them) stays safe. If we changed it to the negated way, then  
whenever we add a new "negated" feature, all (Meta)Engines would have  
to be updated to work correctly. This is bad and breaks the "least  
surprise" principle.


Bye,
Max