[Scummvm-devel] Re: [Scummvm-cvs-logs] CVS: scummvm/base main.cpp,1.48,1.49

[Max Horn]

Am 14.11.2004 um 17:15 schrieb James 'Ender' Brown:

>> This is due to the first line in launcherDialog() where we scale the
>> *current* screen dimensions. A possible fix is to invert the first 2
>> lines in launcherDialog() :
>>
>> 	system->initSize(320, 200);
>> 	system->setGraphicsMode(ConfMan.get("gfx_mode").c_str());
>
> Aha! :) Something to look into.

Inverting those two lines doesn't solve the issue, though, just shifts  
the problem and makes another issue pop up. The real fix is to  
introduce a transaction style API for GFX settings into OSystem (think  
of OpenGL, or databases). Eugene and I already discussed this and will  
implent it in the near future. See also  
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=1013937&group_id=37116&atid=418822>


>
>>>>  o Closing window brings you back to launcher instead of exiting
>>>>    the application
>>>
>>> Thats really a preference issue, but for the SDL backend at least I
>>> suppose you could change the SDL_QUIT event to raise another flag to  
>>> set
>>> running to false in the main loop.
>>
>> Isn't what OSystem::EVENT_QUIT means ? ie. user wants to exit the
>> application ?

Yes, that's what it means. I guess I realls should add docs for all the  
events to common/system.h, it's one of the few parts of the OSystem API  
I haven't documented yet (BTW, feel free to point out other spots you  
think need proper documentation, I'll gladly write it down, if I know  
I'll get feedback on it :-).

Anyway, I added this event, and that's how I meant it to work, and how  
it currently *does* work (except for the changes caused by Ender's hack  
in main(), of course, which changes the way it behaves, which I am not  
happy with, similar to Eugene).


>>
>> Here's how it's handled in the Queen module : when the user choose
>> quit in the 'journal screen', he returns to the launcher. But when
>> he closes the scummvm window (OSystem::EVENT_QUIT is raised), the
>> engine calls g_system->quit().
>
> Thats fine, but there are multiple types of events that raise a
> EVENT_QUIT. In the SDL backend that includes various key combinations  
> as
> well as other events. Although I haven't looked too deeply into it, as  
> I
> said it's a preferences issue and there may need to be seperate events
> for quit and return to launcher.

I don't think so, but if you believe there are triggers for the  
EVENT_QUIT in the SDL backend which shouldn't be there, we can  
discussing moving them out. But Cmd-Q or closing the window, at least  
under Mac OS X, should immediatly quit the app (with the possible  
exception of a "Do you really want to quit?" dialog; of course that  
dialog could also offer a "Return to launcher" button).
The current behaviour, though, IMO is simply incorrect.

Right now, I see no need for a "return to launcher" event. That may  
change, though -- we simply haven't ever talked about UI decisions  
regarding that. I can only state how I imagine this works: The  
frontends may offer a dialog which allows the user to return to the  
launcher. This could be (as above) the "Do you really want to quit?"  
dialog; or in the case of the SCUMM module, would be another button in  
the F5 menu.

The drawback of that would be an inconsistency between the various  
modules. A way around that would be to add a global  
menu/dialog/shortcut, which works in all the games, and allows access  
to some shared settings/functions: Quit, Return to launcher, change GFX  
mode, change volumes.

Note: all these are ideas. They can be combined in various ways.  
Nothing is set in stone yet :-).


> While closing the window (an EVENT_QUIT trigger) may be expected to  
> exit
> thw whole program, I expect the alt-x/alt-q/whatever it was changed to
> key to quickly exit the engine but return to the launcher.

That's very counter-intutitive, though, and introduces a "mode" (Cmd-Q  
/ Alt-X / ...) behaves different depending on when and where you use it  
for no good apparent reason). At least on the mac, I am opposed to such  
changed behavior, it simply would be against the HI specs over here.  
And, on a personal level, "feels" just wrong

>  At the moment that is also an EVENT_QUIT messages, so a distinction  
> needs to be made.

Well, we could, but I believe it's not a solution to the problem at  
hand, just a hack to avoid it :-)
Anyway, we could add a "reason" field to quit events which tells what  
happened exactly (window closed, hotkey pressed, menu item (on OSX)  
chosen, system termination message because the system is shutting down,  
etc.)


Cheers,

Max