[Scummvm-devel] Re: [Scummvm-cvs-logs] CVS: scummvm/base main.cpp,1.48,1.49
Max Horn
max at quendi.de
Mon Nov 15 15:22:09 CET 2004
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
More information about the Scummvm-devel
mailing list