[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