[Scummvm-devel] PROPOSAL: Removing (f)printf usage

Johannes Schickel lordhoto at scummvm.org
Sun Nov 7 02:30:17 CET 2010


On 11/01/2010 01:44 PM, Max Horn wrote:
> Specifically, all code currently using printf should be changed to use either a GUI dialog, error(), warning(), debug(), or *maybe* a new, yet-to-be-introduced function. I'll refer to it as "notify()" for the rest of this text, but the particular name is still up for debate.
>
> The new notify() function can be viewed as a companion to error(), warning() and debug(). Whether we actually need it or not still has to be determined.
>
> In addition, we should write a guidelines which explains when to use which: I.e. when to use warning(), when debug (and debugN, debugC, ...), when notify(), and when to show a GUI dialog instead.

I don't think we should have a "notify" function, that would just give 
the impression it's a good way to notify the user about something, while 
in reality only a few people look at the console (if they have one open 
at all anyway) IMHO. Even with good documentation I bet most people 
would blindly use it.

Apart I agree that we should have some guidelines on when to use 
warning/error and when to use a GUI dialog to notify the user.

> Moreover, we should have a well-defined OSystem API which the code in common/textconsole.cpp and common/debug.cpp uses to perform actual text console output.

Yup :-).


> In the next stage, we would add new OSystem API for text console output, and would change common/textconsole.cpp and common/debug.cpp to use those. On a quick glance, it would seem that something like the following new OSystem methods would be needed:
>
> 1)  OSystem::logToConsole(ConsoleMsgType type, const char *msg);
> Here ConsoleMsgType would be an enum specifying the type of output (e.g. ERROR, WARNING, DEBUG, PLAIN/NOTIFICATION). Backends could then handle different "types" of output differently (e.g. sending some to stdout and some to stderr; or logging them in different files; or prepending them with extra information; etc.).

That looks good, though "logToConsole" seems not the best name. I would 
rather just call it logMessage, appendMessageToLog or something in the 
lines along that, especially since as you mentioned above some ports 
might not even have a console on where to output it ;-).

Oh and of course "PLAIN/NOTIFICATION" shouldn't be there as stated for 
above reasons.

> 2)  OSystem::fatalError()
> This would by called as last thing by error(), and by default would invoke OSystem::quit() followed by exit(1). Look at the end of our current error() function in common/textconsole.cpp to get an idea of what other things backends might do there.
> 2b) Alternatively, this function could be part of OSystem::logToConsole, and triggered by message type FATAL_ERROR.

I don't see why we should have this right now though? I.e. what is the 
possible benefit here? That the backend can still show some "Ooops. 
Something went seriously wrong." message?

> 3) OSystem::flushLog()
> This would correspond to fflush. We currently use this in debug().
> 3b) Alternatively, we could require that logToConsole performs no buffering resp. always does a flush.
>

I actually think that defining that the backend should try to use a no 
buffering output should suffice. It seems overkill to add this method so 
we can use it in a single place.

// Johannes




More information about the Scummvm-devel mailing list